* [PATCH RFC 0/3] per cpuset load average
From: Andrea Righi @ 2012-10-03 23:05 UTC (permalink / raw)
To: Paul Menage, Ingo Molnar, Peter Zijlstra; +Cc: linux-kernel
[ Premise: I'm not considering this patch suitable for inclusion, mostly
because I'm not convinced at all of the interface and I don't even know if
cpuset is the right place for this feature. However, I just wrote it for a
project and I would like to improve it, better integrate it in the kernel and
share the code in general, in case someone else is also interested to use this
feature. ]
Overview
~~~~~~~~
The cpusets subsystem allows to assign a different set of CPUs to a cgroup. A
typical use case is to split large systems in small CPU/memory partitions and
isolate certain users/applications in these subsets of the system.
Sometimes, to have a quick overview of each partition's state, we may be
interested to get the load average of the CPUs assigned to a particular cpuset,
rather than the global load average of the system.
Proposed solution
~~~~~~~~~~~~~~~~~
The proposal is to add a new file in the cpuset subsystem to report the load
average of the CPUs assinged to a particular cpuset cgroup.
Example:
# echo 0-1 > /sys/fs/cgroup/cpuset/foo/cpuset.cpus
# echo 2-3 > /sys/fs/cgroup/cpuset/bar/cpuset.cpus
# echo $$ > /sys/fs/cgroup/cpuset/foo/tasks
# for i in `seq 4`; do yes > /dev/null & done
... after ~5mins ...
# cat /proc/loadavg /sys/fs/cgroup/cpuset/{foo,bar}/cpuset.loadavg
3.99 2.66 1.24 6/377 2855
3.98 2.64 1.20
0.01 0.02 0.04
In this case we can easily find that the cpuset "foo" is the most busy in the
system.
[PATCH RFC 1/3] sched: introduce distinct per-cpu load average
[PATCH RFC 2/3] cpusets: add load avgerage interface
[PATCH RFC 3/3] cpusets: add documentation of the loadavg file
include/linux/sched.h | 7 +++++
kernel/cpuset.c | 58 ++++++++++++++++++++++++++++++++++++
kernel/sched/core.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 139 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH RFC 1/3] sched: introduce distinct per-cpu load average
From: Andrea Righi @ 2012-10-03 23:05 UTC (permalink / raw)
To: Paul Menage, Ingo Molnar, Peter Zijlstra; +Cc: linux-kernel, Andrea Righi
In-Reply-To: <1349305512-3428-1-git-send-email-andrea@betterlinux.com>
Account per-cpu load average, as well as nr_running and
nr_uninterruptible tasks.
The new element on_cpu_uninterruptible to task_struct is added to
properly keep track of the cpu where the task was set to the
uninterruptible sleep state.
This feature is required by the cpusets cgroup subsystem to report the
load average per-cpuset.
Signed-off-by: Andrea Righi <andrea@betterlinux.com>
---
include/linux/sched.h | 7 +++++
kernel/sched/core.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 81 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 9d51e26..fb3df1b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -119,7 +119,10 @@ struct blk_plug;
* 11 bit fractions.
*/
extern unsigned long avenrun[]; /* Load averages */
+extern unsigned long cpu_avenrun[][NR_CPUS] /* Load averages per cpu */;
extern void get_avenrun(unsigned long *loads, unsigned long offset, int shift);
+extern void get_cpu_avenrun(unsigned long *loads, int cpu,
+ unsigned long offset, int shift);
#define FSHIFT 11 /* nr of bits of precision */
#define FIXED_1 (1<<FSHIFT) /* 1.0 as fixed-point */
@@ -138,7 +141,9 @@ extern int nr_threads;
DECLARE_PER_CPU(unsigned long, process_counts);
extern int nr_processes(void);
extern unsigned long nr_running(void);
+extern unsigned long nr_running_cpu(int cpu);
extern unsigned long nr_uninterruptible(void);
+extern unsigned long nr_uninterruptible_cpu(int cpu);
extern unsigned long nr_iowait(void);
extern unsigned long nr_iowait_cpu(int cpu);
extern unsigned long this_cpu_load(void);
@@ -1239,6 +1244,8 @@ struct task_struct {
#ifdef CONFIG_SMP
struct llist_node wake_entry;
int on_cpu;
+ /* Used to keep track of nr_uninterruptible tasks per-cpu */
+ int on_cpu_uninterruptible;
#endif
int on_rq;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c177472..87a8e62 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -727,15 +727,17 @@ static void dequeue_task(struct rq *rq, struct task_struct *p, int flags)
void activate_task(struct rq *rq, struct task_struct *p, int flags)
{
if (task_contributes_to_load(p))
- rq->nr_uninterruptible--;
+ cpu_rq(p->on_cpu_uninterruptible)->nr_uninterruptible--;
enqueue_task(rq, p, flags);
}
void deactivate_task(struct rq *rq, struct task_struct *p, int flags)
{
- if (task_contributes_to_load(p))
- rq->nr_uninterruptible++;
+ if (task_contributes_to_load(p)) {
+ task_rq(p)->nr_uninterruptible++;
+ p->on_cpu_uninterruptible = task_cpu(p);
+ }
dequeue_task(rq, p, flags);
}
@@ -1278,7 +1280,7 @@ ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags)
{
#ifdef CONFIG_SMP
if (p->sched_contributes_to_load)
- rq->nr_uninterruptible--;
+ cpu_rq(p->on_cpu_uninterruptible)->nr_uninterruptible--;
#endif
ttwu_activate(rq, p, ENQUEUE_WAKEUP | ENQUEUE_WAKING);
@@ -1916,6 +1918,11 @@ unsigned long nr_running(void)
return sum;
}
+unsigned long nr_running_cpu(int cpu)
+{
+ return cpu_rq(cpu)->nr_running;
+}
+
unsigned long nr_uninterruptible(void)
{
unsigned long i, sum = 0;
@@ -1933,6 +1940,11 @@ unsigned long nr_uninterruptible(void)
return sum;
}
+unsigned long nr_uninterruptible_cpu(int cpu)
+{
+ return cpu_rq(cpu)->nr_uninterruptible;
+}
+
unsigned long long nr_context_switches(void)
{
int i;
@@ -2035,6 +2047,9 @@ void get_avenrun(unsigned long *loads, unsigned long offset, int shift)
loads[2] = (avenrun[2] + offset) << shift;
}
+unsigned long cpu_avenrun[3][NR_CPUS] __cacheline_aligned_in_smp;
+EXPORT_SYMBOL(cpu_avenrun);
+
static long calc_load_fold_active(struct rq *this_rq)
{
long nr_active, delta = 0;
@@ -2062,6 +2077,24 @@ calc_load(unsigned long load, unsigned long exp, unsigned long active)
return load >> FSHIFT;
}
+static void calc_global_load_percpu(void)
+{
+ long active;
+ int cpu;
+
+ for_each_online_cpu(cpu) {
+ active = cpu_rq(cpu)->calc_load_active;
+ active = active > 0 ? active * FIXED_1 : 0;
+
+ cpu_avenrun[0][cpu] = calc_load(cpu_avenrun[0][cpu],
+ EXP_1, active);
+ cpu_avenrun[1][cpu] = calc_load(cpu_avenrun[1][cpu],
+ EXP_5, active);
+ cpu_avenrun[2][cpu] = calc_load(cpu_avenrun[2][cpu],
+ EXP_15, active);
+ }
+}
+
#ifdef CONFIG_NO_HZ
/*
* Handle NO_HZ for the global load-average.
@@ -2248,6 +2281,23 @@ calc_load_n(unsigned long load, unsigned long exp,
return calc_load(load, fixed_power_int(exp, FSHIFT, n), active);
}
+static void calc_global_load_n_percpu(unsigned int n)
+{
+ long active;
+ int cpu;
+
+ for_each_online_cpu(cpu) {
+ active = cpu_rq(cpu)->calc_load_active;
+ active = active > 0 ? active * FIXED_1 : 0;
+
+ cpu_avenrun[0][cpu] = calc_load_n(cpu_avenrun[0][cpu],
+ EXP_1, active, n);
+ cpu_avenrun[1][cpu] = calc_load_n(cpu_avenrun[1][cpu],
+ EXP_5, active, n);
+ cpu_avenrun[2][cpu] = calc_load_n(cpu_avenrun[2][cpu],
+ EXP_15, active, n);
+ }
+}
/*
* NO_HZ can leave us missing all per-cpu ticks calling
* calc_load_account_active(), but since an idle CPU folds its delta into
@@ -2275,6 +2325,8 @@ static void calc_global_nohz(void)
avenrun[1] = calc_load_n(avenrun[1], EXP_5, active, n);
avenrun[2] = calc_load_n(avenrun[2], EXP_15, active, n);
+ calc_global_load_n_percpu(n);
+
calc_load_update += n * LOAD_FREQ;
}
@@ -2320,6 +2372,8 @@ void calc_global_load(unsigned long ticks)
avenrun[1] = calc_load(avenrun[1], EXP_5, active);
avenrun[2] = calc_load(avenrun[2], EXP_15, active);
+ calc_global_load_percpu();
+
calc_load_update += LOAD_FREQ;
/*
@@ -2328,6 +2382,22 @@ void calc_global_load(unsigned long ticks)
calc_global_nohz();
}
+/**
+ * get_cpu_avenrun - get the load average array of a single cpu
+ * @loads: pointer to dest load array
+ * @cpu: the cpu to read the load average
+ * @offset: offset to add
+ * @shift: shift count to shift the result left
+ *
+ * These values are estimates at best, so no need for locking.
+ */
+void get_cpu_avenrun(unsigned long *loads, int cpu,
+ unsigned long offset, int shift)
+{
+ loads[0] = (cpu_avenrun[0][cpu] + offset) << shift;
+ loads[1] = (cpu_avenrun[1][cpu] + offset) << shift;
+ loads[2] = (cpu_avenrun[2][cpu] + offset) << shift;
+}
/*
* Called from update_cpu_load() to periodically update this CPU's
* active count.
--
1.7.9.5
^ permalink raw reply related
* [U-Boot] [PATCH 1/2] ext4: Rename block group descriptor table from gd to bgd
From: Tom Rini @ 2012-10-03 23:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CALButC+VtaONcEqFRJCQCt65OXqs9QGYTd+1dMPj8NVZVu8Bzw@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/03/12 15:59, Graeme Russ wrote:
> Hi Simon,
>
> On Thu, Oct 4, 2012 at 7:44 AM, Graeme Russ
> <graeme.russ@gmail.com> wrote:
>> Hi Simon,
>>
>> On Oct 4, 2012 6:58 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>>
>>> Hi Graeme,
>>>
>>> On Wed, Oct 3, 2012 at 1:47 PM, Graeme Russ
>>> <graeme.russ@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Oct 4, 2012 6:40 AM, "Simon Glass" <sjg@chromium.org>
>>>> wrote:
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>> On Wed, Oct 3, 2012 at 1:04 PM, Tom Rini <trini@ti.com>
>>>>> wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>>
>>>>>> On 10/03/12 12:53, Simon Glass wrote:
>>>>>>
>>>>>>> On x86 machines gd is unfortunately a #define, so we
>>>>>>> should avoid using gd for anything. This patch changes
>>>>>>> uses of gd to bgd so that ext4fs can be used on x86.
>>>>>>>
>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>
>>>>>> Is there any way to change x86 to not be using a #define
>>>>>> for gd?
>>>>>
>>>>> I wasn't brave enough to look hard at that, although
>>>>> Graeme is on copy and will know. It is actually using
>>>>> inline assembly to access this special variable.
>>>>
>>>> Isn't 'gd' used by everyone (global data)? I fail to see how
>>>> this ever worked.
>>>
>>> Well only x86 uses a #define for it, so other archs cause no
>>> problem. It means that we can't use 'gd' as a symbol anywhere
>>> in U-Boot. I suppose the only sensible use is a structure
>>> member, as here.
>>
>> Ah, I see - and I don't see a quick and easy way out. Let me
>> look a bit deeper...
>
> I remember now... commit 9e6c572ff03cda84c88663b23c7157d8b1f275ac
> explains why the #define gd came about:
>
> "Use the base address of the 'F' segment as a pointer to the
> global data structure. By adding the linear address (i.e. the 'D'
> segment address) as the first word of the global data structure,
> the address of the global data relative to the 'D' segment can be
> found simply, for example, by:
>
> fs movl 0, %eax
>
> This makes the gd 'pointer' writable prior to relocation (by
> reloading the Global Desctriptor Table) which brings x86 into line
> with all other arches
>
> NOTE: Writing to the gd 'pointer' is expensive (but we only do it
> twice) but using it to access global data members (read and write)
> is still fairly cheap"
>
> The other option was rather ugly - create gd_get() and gd_set()
> inline functions and replace all instances of gd-> in all U-Boot
> source with gd_get()-> or gd_set(foo). I don't think it would have
> made any difference to code size, but the amount of code touched
> would have been massive.
>
> The only other option I can think of is to change gd into something
> much less likely to be used as a symbol (__gd for example), but
> again, the patch to do so would be huge
>
> I'm open to alternatives
OK, we'll just go with re-naming the ext4 part and build-testing
things on x86 more often :) Thanks for digging up the details!
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQbMTaAAoJENk4IS6UOR1WWmkP/2eRqqVTtCMwNZ6JP7W/lKDl
bGu2PrIqufPdM2CnQJPpgWWT0PcBIV8thkw5DPhJovjkH7bjFc9bmjXjX6sNZU7V
EnMxU/v6GUdCtM2QKeRv2x7a8iLj2uOcZS4tTg68vA7iD7fj5PwDBTNIGLCSh9EC
VbDo2juPXjz+jSRvuhU7w0MzbeRhwdZ2yACZjlNbnX5TdWam1iXMnxlPPh/pC0Td
ejwy0RuQwHPM7Gxy88b2wIc5DOXn8zoWrqLo1tx8B5S4b6jG+vI8zsFozi4lL9NJ
iCinGd56xDNBIQKPr2NjdpSqkh01efpHqaa7tuBa5mzswNDQikoOXE/ncPFqW618
6kaAHfzCAmSQb/QbwV5576LWw2LcQPGDzz8Mb8iL03nAgHZI8an/blEdJjK6j+1G
EpwzXQ6YkAWnrjCuAMGwfm/ARXai/Qh2YSnT5SPMxIXlWxIfAT7PsBRNbXOLQQp0
M/+NNE25cqAiZqwCxAT/eYR/huJtXbOqOj7GiH9NCn5L8c0Vm3mJ+o+YzRiraNro
D2INZRE1B7347wxb/wkjHlLTfz219RrkSNJE7HBHGPbrtSQOXZaeTa44TZPwZbKP
YuDojx9jMeuVQz1xqAoZECjdIgSEDjNcWcXU6l0JZYQClqDhxtS3GTdnlmMY0kdm
kcZsmBCbojJchtN+VUp8
=0NwK
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH -next] asymmetric keys: fix printk format warning
From: Randy Dunlap @ 2012-10-03 23:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, David Howells, Herbert Xu, linux-crypto,
Andrew Morton
In-Reply-To: <20121003173007.c322d79c31676b9494a6bfd5@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix printk format warning in x509_cert_parser.c:
crypto/asymmetric_keys/x509_cert_parser.c: In function 'x509_note_OID':
crypto/asymmetric_keys/x509_cert_parser.c:113:3: warning: format '%zu' expects type 'size_t', but argument 2 has type 'long unsigned int'
Builds cleanly on i386 and x86_64.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
---
crypto/asymmetric_keys/x509_cert_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20121003.orig/crypto/asymmetric_keys/x509_cert_parser.c
+++ linux-next-20121003/crypto/asymmetric_keys/x509_cert_parser.c
@@ -110,7 +110,7 @@ int x509_note_OID(void *context, size_t
if (ctx->last_oid == OID__NR) {
char buffer[50];
sprint_oid(value, vlen, buffer, sizeof(buffer));
- pr_debug("Unknown OID: [%zu] %s\n",
+ pr_debug("Unknown OID: [%lu] %s\n",
(unsigned long)value - ctx->data, buffer);
}
return 0;
^ permalink raw reply
* [PATCH -next] asymmetric keys: fix printk format warning
From: Randy Dunlap @ 2012-10-03 23:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, David Howells, Herbert Xu, linux-crypto,
Andrew Morton
In-Reply-To: <20121003173007.c322d79c31676b9494a6bfd5@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix printk format warning in x509_cert_parser.c:
crypto/asymmetric_keys/x509_cert_parser.c: In function 'x509_note_OID':
crypto/asymmetric_keys/x509_cert_parser.c:113:3: warning: format '%zu' expects type 'size_t', but argument 2 has type 'long unsigned int'
Builds cleanly on i386 and x86_64.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
---
crypto/asymmetric_keys/x509_cert_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20121003.orig/crypto/asymmetric_keys/x509_cert_parser.c
+++ linux-next-20121003/crypto/asymmetric_keys/x509_cert_parser.c
@@ -110,7 +110,7 @@ int x509_note_OID(void *context, size_t
if (ctx->last_oid == OID__NR) {
char buffer[50];
sprint_oid(value, vlen, buffer, sizeof(buffer));
- pr_debug("Unknown OID: [%zu] %s\n",
+ pr_debug("Unknown OID: [%lu] %s\n",
(unsigned long)value - ctx->data, buffer);
}
return 0;
^ permalink raw reply
* [GIT PULL] user namespace compile fix for 3.7
From: Eric W. Biederman @ 2012-10-03 23:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Bill Pemberton, Greg Kroah-Hartman
Linus,
Please pull the for-linus git tree from:
git://git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus
HEAD: 702e490211b2b7e448ebe1b3a07d97ad2fc07e03 userns: Fix build of drivers/staging/dgrp
This tree contains a trivial build fix for one of the staging drivers
when user namespace support is enabled.
---
Subject: [PATCH] userns: Fix build of drivers/staging/dgrp
Explicitly test for GLOBAL_ROOT_UID and GLOBAL_ROOT_GID
instead of using 0, allowing dgrp to compile and work
properly when user namespace support is enabled.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
drivers/staging/dgrp/dgrp_common.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgrp/dgrp_common.c b/drivers/staging/dgrp/dgrp_common.c
index fce74e7..3553998 100644
--- a/drivers/staging/dgrp/dgrp_common.c
+++ b/drivers/staging/dgrp/dgrp_common.c
@@ -179,9 +179,9 @@ void dgrp_carrier(struct ch_struct *ch)
*/
int dgrp_chk_perm(int mode, int op)
{
- if (!current_euid())
+ if (!uid_eq(GLOBAL_ROOT_UID, current_euid()))
mode >>= 6;
- else if (in_egroup_p(0))
+ else if (in_egroup_p(GLOBAL_ROOT_GID))
mode >>= 3;
if ((mode & op & 0007) == op)
--
1.7.5.4
^ permalink raw reply related
* Re: The BitBake equivalent of "Hello, World!"
From: Rudolf Streif @ 2012-10-03 23:03 UTC (permalink / raw)
To: Patrick Turley; +Cc: yocto@yoctoproject.org
In-Reply-To: <CC922B79.368%PatrickTurley@gamestop.com>
[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]
Hi Patrick,
I think I understand what you are looking for. I created this Bitbake Hello
World for a training class. It just uses 'raw' Bitbake and a very basic
recipe to build the Nano editor (including download from the project site).
You need to have a couple of things in place to make this work. I got to
run but I will get back to it and post it.
:rjs
On Wed, Oct 3, 2012 at 3:56 PM, Patrick Turley
<PatrickTurley@gamestop.com>wrote:
> In my previous message, some of the indentation in the representation of
> my file tree was wrong (because we're using Outlook, which destroy all
> indentation when you paste it into an e-mail message). The errors are
> small, but I want to avoid annoying anyone who might think I don't even
> have the file tree constructed correctly.
>
> The following is accurate:
>
> >/home/pturley/Workspace/woohoo
> > |
> > +-- build
> > | |
> > | +-- classes
> > | | |
> > | | +-- base.bbclass
> > | |
> > | | +-------------------------------------------
> > | | | do_hello() {
> > | | | echo Hello
> > | | | }
> > | | |
> > | | | addtask hello
> > | | +-------------------------------------------
> > | |
> > | +-- conf
> > | |
> > | +-- bblayers.conf
> > | |
> > | | +-------------------------------------------
> > | | | BBLAYERS ?= " \
> > | | | /home/pturley/Workspace/woohoo/LayerA \
> > | | | "
> > | | +-------------------------------------------
> > | |
> > | +-- bitbake.conf
> > |
> > | +-------------------------------------------
> > | | CACHE = "${TOPDIR}/cache"
> > | +-------------------------------------------
> > |
> > +-- LayerA
> > | |
> > | +-- a.bb
> > | |
> > | | +-------------------------------------------
> > | | | PN = 'a'
> > | | | PV = '1'
> > | | +-------------------------------------------
> > | |
> > | +-- conf
> > | |
> > | +-- layer.conf
> > |
> > | +-------------------------------------------
> > | | BBPATH .= ":${LAYERDIR}"
> > | | BBFILES += "${LAYERDIR}/*.bb"
> > | +-------------------------------------------
> > |
> > +-- BitBake ...
> >
> > The BitBake directory origin is:
> >
> > http://git.openembedded.org/bitbake/
> >
> > I have the 1.15.2 tag checked out, which is what
> > Yocto denzil uses.
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
[-- Attachment #2: Type: text/html, Size: 3794 bytes --]
^ permalink raw reply
* Re: Strange problems on iptables (FC17) .... need your help
From: Jan Engelhardt @ 2012-10-03 23:02 UTC (permalink / raw)
To: Ajit K Jena; +Cc: netfilter
In-Reply-To: <1349288885.6825.9.camel@indica.cc.iitb.ac.in>
On Wednesday 2012-10-03 20:28, Ajit K Jena wrote:
>
># The following is to just produce a log of all outgoing packets from
># IPs that are members in the set src_nm_set.
># The set has only one member with IP 10.209.13.6.
>
>-A FORWARD -p tcp -m set --match-set src_nm_set src \
> -m multiport --dports 80:64000 -j LOG --log-level 4 --log-prefix
>"nm_http_outword: "
Why would you allow ports 81 through 64000? That seems like the oddest
range ever, even more so than the usually pointless 1024:65535.
># The following is to just produce a log of all incoming packets
>-A FORWARD -p tcp -m set --match-set src_nm_set dst \
> -m multiport --sports 80:64000 -j LOG --log-level 4 --log-prefix
>"nm_http_inword: "
(outward - inward. No words here.)
> c) The "inward" log entry is **NOT** produced in the logfile.
> d) It appears as if the packet is simply dropped.
> How do I go about debugging this further ?
Log all other packets that are not logged by the outward or inward one.
Their contents may be sufficiently different that your rules don't fire.
^ permalink raw reply
* [U-Boot] [PATCH v4 0/16] tegra: Add display driver and LCD support for Seaboard
From: Stephen Warren @ 2012-10-03 23:00 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1348793077-10126-1-git-send-email-sjg@chromium.org>
On 09/27/2012 06:44 PM, Simon Glass wrote:
> This series adds support for the Tegra2x's display peripheral. This
> supports the LCD display on Seaboard and we use this to enable console
> output in U-Boot on the LCD.
Aside from the comments I made just now, the whole series,
Acked-by: Stephen Warren <swarren@nvidia.com>
At this stage, I figure it's more important to get this feature checked
in and enabled than anything else. For this version of the series, I
only briefly scanned the patches, and mostly concentrated on the device
tree files themselves. They're obviously close enough to the proposed
kernel bindings that we should be able to migrate them easily enough to
the finalized bindings when they're available.
^ permalink raw reply
* [PATCH 4/4] cpufreq: OMAP: use get_cpu_device() instead of omap_device API
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: Rafael J. Wysocki, linux-omap; +Cc: linux-arm-kernel, linux-pm, Paul Walmsley
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
OMAP PM core code has moved to using the existing, generic CPU devices
for attaching OPPs, so the CPUfreq driver can now use the generic
get_cpu_device() API instead of the OMAP-specific omap_device API.
This allows us to remove the last <plat/*> include from this driver.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5d1f5e4..1f3417a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -30,8 +30,6 @@
#include <asm/smp_plat.h>
#include <asm/cpu.h>
-#include <plat/omap_device.h>
-
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
@@ -255,10 +253,10 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- mpu_dev = omap_device_get_by_hwmod_name("mpu");
- if (IS_ERR(mpu_dev)) {
+ mpu_dev = get_cpu_device(0);
+ if (!mpu_dev) {
pr_warning("%s: unable to get the mpu device\n", __func__);
- return PTR_ERR(mpu_dev);
+ return -EINVAL;
}
mpu_reg = regulator_get(mpu_dev, "vcc");
--
1.7.9.2
^ permalink raw reply related
* [PATCH 3/4] cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includes
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: Rafael J. Wysocki, linux-omap; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Paul Walmsley <paul@pwsan.com>
OMAP core code now has SoC-independent clock alias for the scalable
CPU clock. Using it means driver is SoC independent and will work for
AM3xxx SoCs as well as OMAP1/3/4.
While here, remove some unnecessary plat/ includes that are
interfering with multi-subarch ARM kernels.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
[tony@atomide.com: updated already changed clock aliases]
Signed-off-by: Tony Lindgren <tony@atomide.com>
[khilman@ti.com: minor shortlog/changelog updates]
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 7d4d455..5d1f5e4 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -30,19 +30,14 @@
#include <asm/smp_plat.h>
#include <asm/cpu.h>
-#include <plat/clock.h>
-#include <plat/common.h>
#include <plat/omap_device.h>
-#include <mach/hardware.h>
-
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
static struct cpufreq_frequency_table *freq_table;
static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
-static char *mpu_clk_name;
static struct device *mpu_dev;
static struct regulator *mpu_reg;
@@ -179,7 +174,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
- mpu_clk = clk_get(NULL, mpu_clk_name);
+ mpu_clk = clk_get(NULL, "cpufreq_ck");
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
@@ -260,18 +255,6 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- if (cpu_is_omap24xx())
- mpu_clk_name = "virt_prcm_set";
- else if (cpu_is_omap34xx())
- mpu_clk_name = "dpll1_ck";
- else if (cpu_is_omap44xx())
- mpu_clk_name = "dpll_mpu_ck";
-
- if (!mpu_clk_name) {
- pr_err("%s: unsupported Silicon?\n", __func__);
- return -EINVAL;
- }
-
mpu_dev = omap_device_get_by_hwmod_name("mpu");
if (IS_ERR(mpu_dev)) {
pr_warning("%s: unable to get the mpu device\n", __func__);
--
1.7.9.2
^ permalink raw reply related
* [PATCH 2/4] cpufreq: OMAP: remove unused <plat/omap-pm.h>
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: Rafael J. Wysocki, linux-omap; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
The <plat/*.h> headers are going away, and this one is not used. remove it.
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 0fe395a..7d4d455 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -31,7 +31,6 @@
#include <asm/cpu.h>
#include <plat/clock.h>
-#include <plat/omap-pm.h>
#include <plat/common.h>
#include <plat/omap_device.h>
--
1.7.9.2
^ permalink raw reply related
* [PATCH 1/4] cpufreq: OMAP: ensure valid clock rate before scaling
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: Rafael J. Wysocki, linux-omap; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
Ensure the clock rate that will be used is a valid one before
attempting to scale the voltage. Currently the driver assumes it has
a valid frequency from the OPP table, but boards using different
system oscillators might not have exact matches with the OPP table,
and result in a failing call to clk_set_rate().
This is particularily bad because the voltage may be scaled even
though the frequency is not. This will obviously lead to some
unpredictable behavior, especially if the frequency is high and
the voltage is dropped.
Thanks to Joni Lapilainen for reporting crashes seen on 3430/n900.
Reported-by: Joni Lapilainen <joni.lapilainen@gmail.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 65f8e9a..0fe395a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -108,6 +108,14 @@ static int omap_target(struct cpufreq_policy *policy,
}
freq = freqs.new * 1000;
+ ret = clk_round_rate(mpu_clk, freq);
+ if (IS_ERR_VALUE(ret)) {
+ dev_warn(mpu_dev,
+ "CPUfreq: Cannot find matching frequency for %lu\n",
+ freq);
+ return ret;
+ }
+ freq = ret;
if (mpu_reg) {
opp = opp_find_freq_ceil(mpu_dev, &freq);
--
1.7.9.2
^ permalink raw reply related
* [PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: Rafael J. Wysocki, linux-omap; +Cc: linux-arm-kernel, linux-pm
From: Kevin Hilman <khilman@ti.com>
Here's a series with a couple bug fixes and a couple fixes that
make this driver support newer OMAP-based SoCs.
The 'get_cpu_device' patch is needed due to a change in the OMAP
OMAP PM core code which enforces use of get_cpu_device() instead of
a deprecated OMAP-specific API.
The usage of plat/*.h headers breaks single zImage, so platforms are
cleaning up and/or removing plat/*.h so the driver needs to be fixed
accordingly.
This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into
Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603.
Tested CPUfreq on OMAP platforms: 3430/n900, 3530/Overo,
3730/OveroSTORM, 3730/Beagle-XM, 4430/Panda.
Rafael, if you're OK with this series, I'll get a pull request
ASAP so it can be included for v3.7-rc2.
Kevin Hilman (3):
cpufreq: OMAP: ensure valid clock rate before scaling
cpufreq: OMAP: remove unused <plat/omap-pm.h>
cpufreq: OMAP: use get_cpu_device() instead of omap_device API
Paul Walmsley (1):
cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/
includes
drivers/cpufreq/omap-cpufreq.c | 36 ++++++++++++------------------------
1 file changed, 12 insertions(+), 24 deletions(-)
--
1.7.9.2
^ permalink raw reply
* [U-Boot] [U-Boot, 4/6] gpt: Support for GPT (GUID Partition Table) restoration
From: Tom Rini @ 2012-10-03 23:00 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1345795995-24656-5-git-send-email-l.majewski@samsung.com>
On Thu, Aug 23, 2012 at 10:13:13PM -0000, Lukasz Majewski wrote:
> The restoration of GPT table (both primary and secondary) is now possible.
> Simple GUID generation is supported.
>
> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
While the changes are fine, tt01 and eb_cpux9k2 use CONFIG_PART_EFI and
do not set CONFIG_SYS_CACHELINE_SIZE and so fail to build after this
patch. tt01 is easily fixable (it relies on a non-exported define
elsewhere to 32) but the eb_cpu9k2 please contact the listed board
maintainer to get the define added.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121003/8df6c985/attachment.pgp>
^ permalink raw reply
* [PATCH 4/4] cpufreq: OMAP: use get_cpu_device() instead of omap_device API
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
OMAP PM core code has moved to using the existing, generic CPU devices
for attaching OPPs, so the CPUfreq driver can now use the generic
get_cpu_device() API instead of the OMAP-specific omap_device API.
This allows us to remove the last <plat/*> include from this driver.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5d1f5e4..1f3417a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -30,8 +30,6 @@
#include <asm/smp_plat.h>
#include <asm/cpu.h>
-#include <plat/omap_device.h>
-
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
@@ -255,10 +253,10 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- mpu_dev = omap_device_get_by_hwmod_name("mpu");
- if (IS_ERR(mpu_dev)) {
+ mpu_dev = get_cpu_device(0);
+ if (!mpu_dev) {
pr_warning("%s: unable to get the mpu device\n", __func__);
- return PTR_ERR(mpu_dev);
+ return -EINVAL;
}
mpu_reg = regulator_get(mpu_dev, "vcc");
--
1.7.9.2
^ permalink raw reply related
* [PATCH 3/4] cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includes
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Paul Walmsley <paul@pwsan.com>
OMAP core code now has SoC-independent clock alias for the scalable
CPU clock. Using it means driver is SoC independent and will work for
AM3xxx SoCs as well as OMAP1/3/4.
While here, remove some unnecessary plat/ includes that are
interfering with multi-subarch ARM kernels.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
[tony at atomide.com: updated already changed clock aliases]
Signed-off-by: Tony Lindgren <tony@atomide.com>
[khilman at ti.com: minor shortlog/changelog updates]
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 7d4d455..5d1f5e4 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -30,19 +30,14 @@
#include <asm/smp_plat.h>
#include <asm/cpu.h>
-#include <plat/clock.h>
-#include <plat/common.h>
#include <plat/omap_device.h>
-#include <mach/hardware.h>
-
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
static struct cpufreq_frequency_table *freq_table;
static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
-static char *mpu_clk_name;
static struct device *mpu_dev;
static struct regulator *mpu_reg;
@@ -179,7 +174,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
- mpu_clk = clk_get(NULL, mpu_clk_name);
+ mpu_clk = clk_get(NULL, "cpufreq_ck");
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
@@ -260,18 +255,6 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- if (cpu_is_omap24xx())
- mpu_clk_name = "virt_prcm_set";
- else if (cpu_is_omap34xx())
- mpu_clk_name = "dpll1_ck";
- else if (cpu_is_omap44xx())
- mpu_clk_name = "dpll_mpu_ck";
-
- if (!mpu_clk_name) {
- pr_err("%s: unsupported Silicon?\n", __func__);
- return -EINVAL;
- }
-
mpu_dev = omap_device_get_by_hwmod_name("mpu");
if (IS_ERR(mpu_dev)) {
pr_warning("%s: unable to get the mpu device\n", __func__);
--
1.7.9.2
^ permalink raw reply related
* [PATCH 2/4] cpufreq: OMAP: remove unused <plat/omap-pm.h>
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
The <plat/*.h> headers are going away, and this one is not used. remove it.
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 0fe395a..7d4d455 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -31,7 +31,6 @@
#include <asm/cpu.h>
#include <plat/clock.h>
-#include <plat/omap-pm.h>
#include <plat/common.h>
#include <plat/omap_device.h>
--
1.7.9.2
^ permalink raw reply related
* [PATCH 1/4] cpufreq: OMAP: ensure valid clock rate before scaling
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
Ensure the clock rate that will be used is a valid one before
attempting to scale the voltage. Currently the driver assumes it has
a valid frequency from the OPP table, but boards using different
system oscillators might not have exact matches with the OPP table,
and result in a failing call to clk_set_rate().
This is particularily bad because the voltage may be scaled even
though the frequency is not. This will obviously lead to some
unpredictable behavior, especially if the frequency is high and
the voltage is dropped.
Thanks to Joni Lapilainen for reporting crashes seen on 3430/n900.
Reported-by: Joni Lapilainen <joni.lapilainen@gmail.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 65f8e9a..0fe395a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -108,6 +108,14 @@ static int omap_target(struct cpufreq_policy *policy,
}
freq = freqs.new * 1000;
+ ret = clk_round_rate(mpu_clk, freq);
+ if (IS_ERR_VALUE(ret)) {
+ dev_warn(mpu_dev,
+ "CPUfreq: Cannot find matching frequency for %lu\n",
+ freq);
+ return ret;
+ }
+ freq = ret;
if (mpu_reg) {
opp = opp_find_freq_ceil(mpu_dev, &freq);
--
1.7.9.2
^ permalink raw reply related
* [PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
Here's a series with a couple bug fixes and a couple fixes that
make this driver support newer OMAP-based SoCs.
The 'get_cpu_device' patch is needed due to a change in the OMAP
OMAP PM core code which enforces use of get_cpu_device() instead of
a deprecated OMAP-specific API.
The usage of plat/*.h headers breaks single zImage, so platforms are
cleaning up and/or removing plat/*.h so the driver needs to be fixed
accordingly.
This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into
Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603.
Tested CPUfreq on OMAP platforms: 3430/n900, 3530/Overo,
3730/OveroSTORM, 3730/Beagle-XM, 4430/Panda.
Rafael, if you're OK with this series, I'll get a pull request
ASAP so it can be included for v3.7-rc2.
Kevin Hilman (3):
cpufreq: OMAP: ensure valid clock rate before scaling
cpufreq: OMAP: remove unused <plat/omap-pm.h>
cpufreq: OMAP: use get_cpu_device() instead of omap_device API
Paul Walmsley (1):
cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/
includes
drivers/cpufreq/omap-cpufreq.c | 36 ++++++++++++------------------------
1 file changed, 12 insertions(+), 24 deletions(-)
--
1.7.9.2
^ permalink raw reply
* [PATCH 4/4] ACPI: remove acpi_op_start workaround
From: Yinghai Lu @ 2012-10-03 23:00 UTC (permalink / raw)
To: Len Brown, Bjorn Helgaas, Greg Kroah-Hartman
Cc: Andrew Morton, Linus Torvalds, linux-pci, linux-kernel,
linux-acpi, Yinghai Lu
In-Reply-To: <1349305214-3241-1-git-send-email-yinghai@kernel.org>
No .start on any acpi_driver ops anymore.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/acpi/scan.c | 95 ++++++++--------------------------------------
include/acpi/acpi_bus.h | 8 ----
2 files changed, 17 insertions(+), 86 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 1bafa2d..5e6d2ad 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -416,7 +416,6 @@ static void acpi_device_remove_notify_handler(struct acpi_device *device)
}
static int acpi_bus_driver_init(struct acpi_device *, struct acpi_driver *);
-static int acpi_start_single_object(struct acpi_device *);
static int acpi_device_probe(struct device * dev)
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
@@ -425,9 +424,6 @@ static int acpi_device_probe(struct device * dev)
ret = acpi_bus_driver_init(acpi_dev, acpi_drv);
if (!ret) {
- if (acpi_dev->bus_ops.acpi_op_start)
- acpi_start_single_object(acpi_dev);
-
if (acpi_drv->ops.notify) {
ret = acpi_device_install_notify_handler(acpi_dev);
if (ret) {
@@ -604,24 +600,6 @@ acpi_bus_driver_init(struct acpi_device *device, struct acpi_driver *driver)
return 0;
}
-static int acpi_start_single_object(struct acpi_device *device)
-{
- int result = 0;
- struct acpi_driver *driver;
-
-
- if (!(driver = device->driver))
- return 0;
-
- if (driver->ops.start) {
- result = driver->ops.start(device);
- if (result && driver->ops.remove)
- driver->ops.remove(device, ACPI_BUS_REMOVAL_NORMAL);
- }
-
- return result;
-}
-
/**
* acpi_bus_register_driver - register a driver with the ACPI bus
* @driver: driver being registered
@@ -1254,8 +1232,7 @@ static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
- unsigned long long sta,
- struct acpi_bus_ops *ops)
+ unsigned long long sta)
{
int result;
struct acpi_device *device;
@@ -1271,7 +1248,6 @@ static int acpi_add_single_object(struct acpi_device **child,
device->device_type = type;
device->handle = handle;
device->parent = acpi_bus_get_parent(handle);
- device->bus_ops = *ops; /* workround for not call .start */
STRUCT_TO_INT(device->status) = sta;
device->drivers_autoprobe = true;
@@ -1354,16 +1330,12 @@ end:
static void acpi_bus_add_power_resource(acpi_handle handle)
{
- struct acpi_bus_ops ops = {
- .acpi_op_add = 1,
- .acpi_op_start = 1,
- };
struct acpi_device *device = NULL;
acpi_bus_get_device(handle, &device);
if (!device)
acpi_add_single_object(&device, handle, ACPI_BUS_TYPE_POWER,
- ACPI_STA_DEFAULT, &ops);
+ ACPI_STA_DEFAULT);
}
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
@@ -1408,7 +1380,6 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl,
void *context, void **return_value)
{
- struct acpi_bus_ops *ops = context;
int type;
unsigned long long sta;
struct acpi_device *device;
@@ -1433,37 +1404,30 @@ static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl,
/*
* We may already have an acpi_device from a previous enumeration. If
- * so, we needn't add it again, but we may still have to start it.
+ * so, we needn't add it again.
*/
device = NULL;
acpi_bus_get_device(handle, &device);
- if (ops->acpi_op_add && !device)
- acpi_add_single_object(&device, handle, type, sta, ops);
+ if (!device)
+ acpi_add_single_object(&device, handle, type, sta);
if (!device)
return AE_CTRL_DEPTH;
- if (ops->acpi_op_start && !(ops->acpi_op_add)) {
- status = acpi_start_single_object(device);
- if (ACPI_FAILURE(status))
- return AE_CTRL_DEPTH;
- }
-
if (!*return_value)
*return_value = device;
return AE_OK;
}
-static int acpi_bus_scan(acpi_handle handle, struct acpi_bus_ops *ops,
- struct acpi_device **child)
+static int acpi_bus_scan(acpi_handle handle, struct acpi_device **child)
{
acpi_status status;
void *device = NULL;
- status = acpi_bus_check_add(handle, 0, ops, &device);
+ status = acpi_bus_check_add(handle, 0, NULL, &device);
if (ACPI_SUCCESS(status))
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- acpi_bus_check_add, NULL, ops, &device);
+ acpi_bus_check_add, NULL, NULL, &device);
if (child)
*child = device;
@@ -1488,28 +1452,24 @@ static void acpi_bus_attach(struct acpi_device *dev)
}
/*
- * acpi_bus_add and acpi_bus_start
+ * acpi_bus_add
*
* scan a given ACPI tree and (probably recently hot-plugged)
- * create and add or starts found devices.
+ * create and add found devices.
*
* If no devices were found -ENODEV is returned which does not
* mean that this is a real error, there just have been no suitable
* ACPI objects in the table trunk from which the kernel could create
- * a device and add/start an appropriate driver.
+ * a device and add an appropriate driver.
*/
int
acpi_bus_add(struct acpi_device **child,
struct acpi_device *parent, acpi_handle handle, int type)
{
- struct acpi_bus_ops ops;
int result;
- memset(&ops, 0, sizeof(ops));
- ops.acpi_op_add = 1;
-
- result = acpi_bus_scan(handle, &ops, child);
+ result = acpi_bus_scan(handle, child);
if (*child)
acpi_bus_attach(*child);
@@ -1520,20 +1480,12 @@ EXPORT_SYMBOL(acpi_bus_add);
int acpi_bus_start(struct acpi_device *device)
{
- struct acpi_bus_ops ops;
- int result;
-
if (!device)
return -EINVAL;
- memset(&ops, 0, sizeof(ops));
- ops.acpi_op_start = 1;
-
- result = acpi_bus_scan(device->handle, &ops, NULL);
-
acpi_update_all_gpes();
- return result;
+ return 0;
}
EXPORT_SYMBOL(acpi_bus_start);
@@ -1596,11 +1548,6 @@ static int acpi_bus_scan_fixed(void)
{
int result = 0;
struct acpi_device *device = NULL;
- struct acpi_bus_ops ops;
-
- memset(&ops, 0, sizeof(ops));
- ops.acpi_op_add = 1;
- ops.acpi_op_start = 1;
/*
* Enumerate all fixed-feature devices.
@@ -1608,17 +1555,14 @@ static int acpi_bus_scan_fixed(void)
if ((acpi_gbl_FADT.flags & ACPI_FADT_POWER_BUTTON) == 0) {
result = acpi_add_single_object(&device, NULL,
ACPI_BUS_TYPE_POWER_BUTTON,
- ACPI_STA_DEFAULT,
- &ops);
+ ACPI_STA_DEFAULT);
device_init_wakeup(&device->dev, true);
}
- if ((acpi_gbl_FADT.flags & ACPI_FADT_SLEEP_BUTTON) == 0) {
+ if ((acpi_gbl_FADT.flags & ACPI_FADT_SLEEP_BUTTON) == 0)
result = acpi_add_single_object(&device, NULL,
ACPI_BUS_TYPE_SLEEP_BUTTON,
- ACPI_STA_DEFAULT,
- &ops);
- }
+ ACPI_STA_DEFAULT);
return result;
}
@@ -1626,11 +1570,6 @@ static int acpi_bus_scan_fixed(void)
int __init acpi_scan_init(void)
{
int result;
- struct acpi_bus_ops ops;
-
- memset(&ops, 0, sizeof(ops));
- ops.acpi_op_add = 1;
- ops.acpi_op_start = 1;
result = bus_register(&acpi_bus_type);
if (result) {
@@ -1643,7 +1582,7 @@ int __init acpi_scan_init(void)
/*
* Enumerate devices in the ACPI namespace.
*/
- result = acpi_bus_scan(ACPI_ROOT_OBJECT, &ops, &acpi_root);
+ result = acpi_bus_scan(ACPI_ROOT_OBJECT, &acpi_root);
if (!result)
result = acpi_bus_scan_fixed();
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 969544e..cc9363b 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -119,20 +119,13 @@ struct acpi_device;
typedef int (*acpi_op_add) (struct acpi_device * device);
typedef int (*acpi_op_remove) (struct acpi_device * device, int type);
-typedef int (*acpi_op_start) (struct acpi_device * device);
typedef int (*acpi_op_bind) (struct acpi_device * device);
typedef int (*acpi_op_unbind) (struct acpi_device * device);
typedef void (*acpi_op_notify) (struct acpi_device * device, u32 event);
-struct acpi_bus_ops {
- u32 acpi_op_add:1;
- u32 acpi_op_start:1;
-};
-
struct acpi_device_ops {
acpi_op_add add;
acpi_op_remove remove;
- acpi_op_start start;
acpi_op_bind bind;
acpi_op_unbind unbind;
acpi_op_notify notify;
@@ -302,7 +295,6 @@ struct acpi_device {
struct acpi_driver *driver;
void *driver_data;
struct device dev;
- struct acpi_bus_ops bus_ops; /* workaround for different code path for hotplug */
enum acpi_bus_removal_type removal_type; /* indicate for different removal type */
bool drivers_autoprobe;
};
--
1.7.7
^ permalink raw reply related
* [PATCH 3/4] PCI, ACPI: Remove not used acpi_pci_root_start()
From: Yinghai Lu @ 2012-10-03 23:00 UTC (permalink / raw)
To: Len Brown, Bjorn Helgaas, Greg Kroah-Hartman
Cc: Andrew Morton, Linus Torvalds, linux-pci, linux-kernel,
linux-acpi, Yinghai Lu
In-Reply-To: <1349305214-3241-1-git-send-email-yinghai@kernel.org>
Now with new acpi_bus_add, we could move code in acpi_pci_root_start into
acpi_pci_root_add.
After that we could remove acpi_pci_root_start.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/acpi/pci_root.c | 27 +++++++++------------------
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index bce469c..8d85287 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -47,7 +47,6 @@ ACPI_MODULE_NAME("pci_root");
#define ACPI_PCI_ROOT_DEVICE_NAME "PCI Root Bridge"
static int acpi_pci_root_add(struct acpi_device *device);
static int acpi_pci_root_remove(struct acpi_device *device, int type);
-static int acpi_pci_root_start(struct acpi_device *device);
#define ACPI_PCIE_REQ_SUPPORT (OSC_EXT_PCI_CONFIG_SUPPORT \
| OSC_ACTIVE_STATE_PWR_SUPPORT \
@@ -67,7 +66,6 @@ static struct acpi_driver acpi_pci_root_driver = {
.ops = {
.add = acpi_pci_root_add,
.remove = acpi_pci_root_remove,
- .start = acpi_pci_root_start,
},
};
@@ -451,6 +449,7 @@ static int __devinit acpi_pci_root_add(struct acpi_device *device)
acpi_status status;
int result;
struct acpi_pci_root *root;
+ struct acpi_pci_driver *driver;
acpi_handle handle;
struct acpi_device *child;
u32 flags, base_flags;
@@ -628,22 +627,6 @@ static int __devinit acpi_pci_root_add(struct acpi_device *device)
if (device->wakeup.flags.run_wake)
device_set_run_wake(root->bus->bridge, true);
- return 0;
-
-out_del_root:
- mutex_lock(&acpi_pci_root_lock);
- list_del(&root->node);
- mutex_unlock(&acpi_pci_root_lock);
-end:
- kfree(root);
- return result;
-}
-
-static int acpi_pci_root_start(struct acpi_device *device)
-{
- struct acpi_pci_root *root = acpi_driver_data(device);
- struct acpi_pci_driver *driver;
-
mutex_lock(&acpi_pci_root_lock);
list_for_each_entry(driver, &acpi_pci_drivers, node)
if (driver->add)
@@ -653,6 +636,14 @@ static int acpi_pci_root_start(struct acpi_device *device)
pci_bus_add_devices(root->bus);
return 0;
+
+out_del_root:
+ mutex_lock(&acpi_pci_root_lock);
+ list_del(&root->node);
+ mutex_unlock(&acpi_pci_root_lock);
+end:
+ kfree(root);
+ return result;
}
static int acpi_pci_root_remove(struct acpi_device *device, int type)
--
1.7.7
^ permalink raw reply related
* [PATCH 2/4] ACPI: use device drivers_autoprobe to delay loading acpi drivers
From: Yinghai Lu @ 2012-10-03 23:00 UTC (permalink / raw)
To: Len Brown, Bjorn Helgaas, Greg Kroah-Hartman
Cc: Andrew Morton, Linus Torvalds, linux-pci, linux-kernel,
linux-acpi, Yinghai Lu
In-Reply-To: <1349305214-3241-1-git-send-email-yinghai@kernel.org>
Current acpi driver for pci_root is working like this way for hotplug:
acpi try to enumberate acpi device and create acpi_device for pci_root
and loading driver for it, and that drivers .add aka acpi_pci_root_add
calls pci_acpi_scan_root to enumerate pci devices but not add those pci
devices into device tree to prevent drivers for pci devices get probed.
Later .start aka acpi_pci_root_start will call pci_bus_add_devices to
add pci devices into the tree to make drivers for pci devices get
attached or probed.
The reason for that .add must get back for pci_root, so could create acpi_device
for other pci_devices. otherwise adding the pci device tree early than
acpi_device will cause binding for acpi/pci failing becuse pci_device can not
find acpi_dev that is not created yet.
booting path is working becasue driver for acpi driver is registered later,
that means all acpi_device get created at first, and later when acpi_driver
get registered, and .add get called, that probe pci devices, when pci devices
is found, it could find acpi_device and binding will be ok, even
pci_add_bus_devices in done in acpi_pci_root_add.
That .start design is broken, and it will leave pci devices out of device tree
for a while.
We could use device drivers_autoprobe and acpi_bus_type notifier to control
the process to make sure for hot adding path, will have all acpi_device get
created, then attach acpi driver for acpi_device for pci_root.
That will make the path more like booting path.
After that we could remove the workaround .start in acpi driver ops.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/acpi/scan.c | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index cbb3ed1..1bafa2d 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1474,6 +1474,19 @@ static int acpi_bus_scan(acpi_handle handle, struct acpi_bus_ops *ops,
return -ENODEV;
}
+static void acpi_bus_attach(struct acpi_device *dev)
+{
+ struct acpi_device *child;
+ int ret;
+
+ dev->drivers_autoprobe = true;
+ ret = device_attach(&dev->dev);
+ WARN_ON(ret < 0);
+
+ list_for_each_entry(child, &dev->children, node)
+ acpi_bus_attach(child);
+}
+
/*
* acpi_bus_add and acpi_bus_start
*
@@ -1491,11 +1504,17 @@ acpi_bus_add(struct acpi_device **child,
struct acpi_device *parent, acpi_handle handle, int type)
{
struct acpi_bus_ops ops;
+ int result;
memset(&ops, 0, sizeof(ops));
ops.acpi_op_add = 1;
- return acpi_bus_scan(handle, &ops, child);
+ result = acpi_bus_scan(handle, &ops, child);
+
+ if (*child)
+ acpi_bus_attach(*child);
+
+ return result;
}
EXPORT_SYMBOL(acpi_bus_add);
@@ -1636,3 +1655,28 @@ int __init acpi_scan_init(void)
return result;
}
+
+static int acpi_hp_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct device *dev = data;
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ to_acpi_device(dev)->drivers_autoprobe = false;
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block acpi_hp_nb = {
+ .notifier_call = &acpi_hp_notifier,
+};
+
+static int __init acpi_hp_init(void)
+{
+ return bus_register_notifier(&acpi_bus_type, &acpi_hp_nb);
+}
+
+fs_initcall(acpi_hp_init);
--
1.7.7
^ permalink raw reply related
* [PATCH 1/4] ACPI: add drivers_autoprobe in struct acpi_device
From: Yinghai Lu @ 2012-10-03 23:00 UTC (permalink / raw)
To: Len Brown, Bjorn Helgaas, Greg Kroah-Hartman
Cc: Andrew Morton, Linus Torvalds, linux-pci, linux-kernel,
linux-acpi, Yinghai Lu
In-Reply-To: <1349305214-3241-1-git-send-email-yinghai@kernel.org>
To use to control the delay attach driver for acpi_device.
Will use bus notifier to toggle this bits when needed.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/acpi/scan.c | 8 +++++++-
include/acpi/acpi_bus.h | 1 +
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index d1ecca2..cbb3ed1 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -333,7 +333,12 @@ static void acpi_device_release(struct device *dev)
static int acpi_bus_match(struct device *dev, struct device_driver *drv)
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
- struct acpi_driver *acpi_drv = to_acpi_driver(drv);
+ struct acpi_driver *acpi_drv;
+
+ if (!acpi_dev->drivers_autoprobe)
+ return 0;
+
+ acpi_drv = to_acpi_driver(drv);
return !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
}
@@ -1268,6 +1273,7 @@ static int acpi_add_single_object(struct acpi_device **child,
device->parent = acpi_bus_get_parent(handle);
device->bus_ops = *ops; /* workround for not call .start */
STRUCT_TO_INT(device->status) = sta;
+ device->drivers_autoprobe = true;
acpi_device_get_busid(device);
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index bde976e..969544e 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -304,6 +304,7 @@ struct acpi_device {
struct device dev;
struct acpi_bus_ops bus_ops; /* workaround for different code path for hotplug */
enum acpi_bus_removal_type removal_type; /* indicate for different removal type */
+ bool drivers_autoprobe;
};
static inline void *acpi_driver_data(struct acpi_device *d)
--
1.7.7
^ permalink raw reply related
* [PATCH 0/4] ACPI: kill acpi_pci_root_start
From: Yinghai Lu @ 2012-10-03 23:00 UTC (permalink / raw)
To: Len Brown, Bjorn Helgaas, Greg Kroah-Hartman
Cc: Andrew Morton, Linus Torvalds, linux-pci, linux-kernel,
linux-acpi, Yinghai Lu
In-Reply-To: <CAE9FiQWgvVqnTTeYFvxf1GxLcEEeRyN-uSKPdg3o69oCpm43sQ@mail.gmail.com>
Now acpi_pci_root_driver has two ops: .add and .start, aka acpi_pci_root_add
and acpi_pci_root_start.
That is for hotplug handling: .add need to return early to make sure all
acpi device could be created and added early. So .start could device_add
pci device that are found in acpi_pci_root_add/pci_acpi_scan_root().
That is holding pci devics to be out of devices for while.
We could use bus notifier to handle hotplug case.
CONFIG_HOTPLUG is enabled always now.
Need to add drivers_autoprobe bit in acpi_device to hold attaching drivers
for acpi_devices, so could make sure all acpi_devices get created at first.
Then acpi_bus_attach() that is called from acpi_bus_add will attach driver
for all acpi_devices that are just created.
That make the logic more simple: hotplug path handling just like booting path
that drivers are attached after all acpi device get created.
At last we could remove all acpi_bus_start workaround.
Thanks
Yinghai
Yinghai Lu (4):
ACPI: add drivers_autoprobe in struct acpi_device
ACPI: use device drivers_autoprobe to delay loading acpi drivers
PCI, ACPI: Remove not used acpi_pci_root_start()
ACPI: remove acpi_op_start workaround
drivers/acpi/pci_root.c | 27 +++------
drivers/acpi/scan.c | 145 ++++++++++++++++++++++-------------------------
include/acpi/acpi_bus.h | 9 +---
3 files changed, 77 insertions(+), 104 deletions(-)
--
1.7.7
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.