Re: [PATCH 00/36] AArch64 Linux kernel port
On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote: > Yes, I agree that's the best way to handle this. Compared to other > architectures, I think x86 is the only that allows booting either a > 32 or 64 bit kernel on the same system. We used to support 32 bit > kernels on 64 bit PowerMac, but nobody used it and we discontinued > it long ago. Tile 64 bit is actually incompatible with 32 bit kernels > at the architecture level and would require a third mode. On sparc, > parisc and mips, AFAIK we could support 32 bit kernels on 64 bit > machines, but never did. On mips it works just fine. On Sparc I don't think Linux ever did it, but Solaris did for a long time, as did (IIRC) NetBSD/OpenBSD. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for July 12 (v4l2-ioctl.c)
On Tue July 17 2012 04:25:35 Ming Lei wrote: > On Thu, Jul 12, 2012 at 11:49 PM, Randy Dunlap wrote: > > On 07/11/2012 11:03 PM, Stephen Rothwell wrote: > > > >> Hi all, > >> > >> Changes since 20120710: > > > > > > > > on i386 and/or x86_64, drivers/media/video/v4l2-ioctl.c has too many > > errors to be listed here. This is the beginning few lines of the errors: > > I see the errors on ARM too. A fix can be found here: http://patchwork.linuxtv.org/patch/13336/ Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
>From cea5f76c3ad9f42b85a1a71b75035fe96317187a Mon Sep 17 00:00:00 2001
From: Jovi Zhang
Date: Tue, 17 Jul 2012 22:43:11 +0800
Subject: [PATCH] ftrace: using pr_fmt for better printk output
There don't have subsystem name output in front ot ftrace related log entry,
so use pr_fmt to enable better printk output, for output subsystem name in
log entry.
Signed-off-by: Jovi Zhang
---
kernel/trace/blktrace.c |2 ++
kernel/trace/ftrace.c| 11 ++-
kernel/trace/trace.c |5 -
kernel/trace/trace_events.c |2 ++
kernel/trace/trace_functions_graph.c |9 ++---
kernel/trace/trace_kprobe.c |2 ++
kernel/trace/trace_mmiotrace.c |2 ++
kernel/trace/trace_probe.c |2 ++
kernel/trace/trace_selftest.c|6 +++---
kernel/trace/trace_syscalls.c|8
kernel/trace/trace_uprobe.c |2 ++
11 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index c0bd030..65c521f 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -15,6 +15,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index a008663..1198ebd 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -13,6 +13,8 @@
* Copyright (C) 2004 William Lee Irwin III
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -2178,7 +2180,7 @@ ftrace_allocate_pages(unsigned long num_to_init)
kfree(pg);
pg = start_pg;
}
- pr_info("ftrace: FAILED to allocate memory for functions\n");
+ pr_info("FAILED to allocate memory for functions\n");
return NULL;
}
@@ -2187,12 +2189,12 @@ static int __init
ftrace_dyn_table_alloc(unsigned long num_to_init)
int cnt;
if (!num_to_init) {
- pr_info("ftrace: No functions to be traced?\n");
+ pr_info("No functions to be traced?\n");
return -1;
}
cnt = num_to_init / ENTRIES_PER_PAGE;
- pr_info("ftrace: allocating %ld entries in %d pages\n",
+ pr_info("allocating %ld entries in %d pages\n",
num_to_init, cnt + 1);
return 0;
@@ -4495,8 +4497,7 @@ static int start_graph_tracing(void)
if (!ret) {
ret =
register_trace_sched_switch(ftrace_graph_probe_sched_switch, NULL);
if (ret)
- pr_info("ftrace_graph: Couldn't activate tracepoint"
- " probe to kernel_sched_switch\n");
+ pr_info("Couldn't activate tracepoint probe to
kernel_sched_switch\n");
}
kfree(ret_stack_list);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index a7fa070..265f4a5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -11,6 +11,9 @@
* Copyright (C) 2004-2006 Ingo Molnar
* Copyright (C) 2004 William Lee Irwin III
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -1566,7 +1569,7 @@ void trace_printk_init_buffers(void)
if (alloc_percpu_trace_buffer())
return;
- pr_info("ftrace: Allocated trace_printk buffers\n");
+ pr_info("Allocated trace_printk buffers\n");
buffers_allocated = 1;
}
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 29111da..11dd55c 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -8,6 +8,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
diff --git a/kernel/trace/trace_functions_graph.c
b/kernel/trace/trace_functions_graph.c
index a7d2a4c..a2be82b 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -6,6 +6,9 @@
* is Copyright (c) Steven Rostedt
*
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -1401,7 +1404,7 @@ void graph_trace_open(struct trace_iterator *iter)
out_err_free:
kfree(data);
out_err:
- pr_warning("function graph tracer: not enough memory\n");
+ pr_warn("not enough memory\n");
}
void graph_trace_close(struct trace_iterator *iter)
@@ -1459,12 +1462,12 @@ static __init int init_graph_trace(void)
max_bytes_for_cpu = snprintf(NULL, 0, "%d", nr_cpu_ids - 1);
if (!register_ftrace_event(&graph_trace_entry_event)) {
- pr_warning("Warning: could not register graph trace events\n");
+ pr_warn("Warning: could not register graph trace events\n");
return 1;
}
if (!register_ftrace_event(&graph_trace_ret_event)) {
- pr_warning("Warning: could not register graph trace events\n");
+ pr_w
[PATCH RFT] regulator: s2mps11: Fix ramp_delay settings for s2mps11_buck_ops
The ramp_delay settings were missing while converting to
regulator_set_voltage_time_sel(). Fix it.
There is no ramp_delay setting for s2mps11_ldo_ops, thus remove
setting set_voltage_sel callback for s2mps11_ldo_ops.
Signed-off-by: Axel Lin
---
drivers/regulator/s2mps11.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 4669dc9..b0f7ac1 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -62,7 +62,6 @@ static struct regulator_ops s2mps11_ldo_ops = {
.disable= regulator_disable_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
- .set_voltage_time_sel = regulator_set_voltage_time_sel,
};
static struct regulator_ops s2mps11_buck_ops = {
@@ -291,6 +290,32 @@ static __devinit int s2mps11_pmic_probe(struct
platform_device *pdev)
sec_reg_write(iodev, S2MPS11_REG_RAMP_BUCK, ramp_reg);
for (i = 0; i < S2MPS11_REGULATOR_MAX; i++) {
+ struct regulator_desc *desc = ®ulators[i];
+
+ switch (i) {
+ case S2MPS11_BUCK1:
+ case S2MPS11_BUCK6:
+ desc->ramp_delay = pdata->buck16_ramp_delay * 1000;
+ break;
+ case S2MPS11_BUCK2:
+ desc->ramp_delay = pdata->buck2_ramp_delay * 1000;
+ break;
+ case S2MPS11_BUCK3:
+ case S2MPS11_BUCK4:
+ desc->ramp_delay = pdata->buck34_ramp_delay * 1000;
+ break;
+ case S2MPS11_BUCK5:
+ desc->ramp_delay = pdata->buck5_ramp_delay * 1000;
+ break;
+ case S2MPS11_BUCK7:
+ case S2MPS11_BUCK8:
+ case S2MPS11_BUCK10:
+ desc->ramp_delay = pdata->buck7810_ramp_delay * 1000;
+ break;
+ case S2MPS11_BUCK9:
+ desc->ramp_delay = pdata->buck9_ramp_delay * 1000;
+ break;
+ }
config.dev = &pdev->dev;
config.regmap = iodev->regmap;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] 3.4.x: hrtimer: Update hrtimer base offsets each hrtimer_interrupt
This is a backport of 5baefd6d84163443215f4a99f6a20f054ef11236
The update of the hrtimer base offsets on all cpus cannot be made
atomically from the timekeeper.lock held and interrupt disabled region
as smp function calls are not allowed there.
clock_was_set(), which enforces the update on all cpus, is called
either from preemptible process context in case of do_settimeofday()
or from the softirq context when the offset modification happened in
the timer interrupt itself due to a leap second.
In both cases there is a race window for an hrtimer interrupt between
dropping timekeeper lock, enabling interrupts and clock_was_set()
issuing the updates. Any interrupt which arrives in that window will
see the new time but operate on stale offsets.
So we need to make sure that an hrtimer interrupt always sees a
consistent state of time and offsets.
ktime_get_update_offsets() allows us to get the current monotonic time
and update the per cpu hrtimer base offsets from hrtimer_interrupt()
to capture a consistent state of monotonic time and the offsets. The
function replaces the existing ktime_get() calls in hrtimer_interrupt().
The overhead of the new function vs. ktime_get() is minimal as it just
adds two store operations.
This ensures that any changes to realtime or boottime offsets are
noticed and stored into the per-cpu hrtimer base structures, prior to
any hrtimer expiration and guarantees that timers are not expired early.
Signed-off-by: John Stultz
Reviewed-by: Ingo Molnar
Acked-by: Peter Zijlstra
Acked-by: Prarit Bhargava
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1341960205-56738-8-git-send-email-johns...@us.ibm.com
Signed-off-by: Thomas Gleixner
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Linux Kernel
Signed-off-by: John Stultz
---
kernel/hrtimer.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 8f320af..6db7a5e 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -657,6 +657,14 @@ static inline int hrtimer_enqueue_reprogram(struct hrtimer
*timer,
return 0;
}
+static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base)
+{
+ ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset;
+ ktime_t *offs_boot = &base->clock_base[HRTIMER_BASE_BOOTTIME].offset;
+
+ return ktime_get_update_offsets(offs_real, offs_boot);
+}
+
/*
* Retrigger next event is called after clock was set
*
@@ -665,22 +673,12 @@ static inline int hrtimer_enqueue_reprogram(struct
hrtimer *timer,
static void retrigger_next_event(void *arg)
{
struct hrtimer_cpu_base *base = &__get_cpu_var(hrtimer_bases);
- struct timespec realtime_offset, xtim, wtm, sleep;
if (!hrtimer_hres_active())
return;
- /* Optimized out for !HIGH_RES */
- get_xtime_and_monotonic_and_sleep_offset(&xtim, &wtm, &sleep);
- set_normalized_timespec(&realtime_offset, -wtm.tv_sec, -wtm.tv_nsec);
-
- /* Adjust CLOCK_REALTIME offset */
raw_spin_lock(&base->lock);
- base->clock_base[HRTIMER_BASE_REALTIME].offset =
- timespec_to_ktime(realtime_offset);
- base->clock_base[HRTIMER_BASE_BOOTTIME].offset =
- timespec_to_ktime(sleep);
-
+ hrtimer_update_base(base);
hrtimer_force_reprogram(base, 0);
raw_spin_unlock(&base->lock);
}
@@ -710,7 +708,6 @@ static int hrtimer_switch_to_hres(void)
base->clock_base[i].resolution = KTIME_HIGH_RES;
tick_setup_sched_timer();
-
/* "Retrigger" the interrupt to get things going */
retrigger_next_event(NULL);
local_irq_restore(flags);
@@ -1264,7 +1261,7 @@ void hrtimer_interrupt(struct clock_event_device *dev)
dev->next_event.tv64 = KTIME_MAX;
raw_spin_lock(&cpu_base->lock);
- entry_time = now = ktime_get();
+ entry_time = now = hrtimer_update_base(cpu_base);
retry:
expires_next.tv64 = KTIME_MAX;
/*
@@ -1342,9 +1339,12 @@ retry:
* We need to prevent that we loop forever in the hrtimer
* interrupt routine. We give it 3 attempts to avoid
* overreacting on some spurious event.
+*
+* Acquire base lock for updating the offsets and retrieving
+* the current time.
*/
raw_spin_lock(&cpu_base->lock);
- now = ktime_get();
+ now = hrtimer_update_base(cpu_base);
cpu_base->nr_retries++;
if (++retries < 3)
goto retry;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kerneloops.org defunct?
On Tue, 2012-06-26 at 09:14 +0200, Anton Arapov wrote:
> On Mon, Jun 25, 2012 at 12:12:33PM -0700, Guenter Roeck wrote:
> > On Mon, Jun 25, 2012 at 11:11:12AM -0700, Arjan van de Ven wrote:
> > > On 6/25/2012 11:05 AM, Guenter Roeck wrote:
> > > > Did anyone ever get access to the kerneloops code and/or is working on a
> > > > replacement ?
> > > > I see that http://kerneloops-descope.rhcloud.com/submitoops.php appears
> > > > to
> > > > accept kerneloops reports, http://kerneloops-descope.rhcloud.com/
> > > > reports
> > > > "www.kerneloops.org, coming soon", and a comment in
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=800302 suggests that Redhat
> > > > may be
> > > > in the process of taking over kerneloops.org.
> > > I hope RH is willing to invest the time in this; I do not have access to
> > > the latest code anymore (it lived on the kernel.org servers prior to the
> > > incident)
> > Maybe we can get some feedback from RH. Anton, can you shed some light about
> > what is happening, if anything ?
>
> I can't promise, but there will be a person in Red Hat, who will be
> working on 'kerneloops.org' starting from middle of next month. I will
> update you in a couple weeks whether it happened or not.
Unfortunately, still no person to work on project. And there are only
2- reports a month in average. :(
The reporting tool(Abrt) complicated the reporting and kerneloops.org
DNS still doesn't associated with the required ip address. ( Arjan? )
- Abrt folks pushed changes into Fedora 17 that makes possible to set
a checkbox("don't ask me again, just report") and Abrt will send reports
without asking.
- Starting from the Fedora 18 kernel oopses reporting will be
configured to send reports unconditionally, straight to the
kerneloops.org as it did the original tool.
(this, hopefully, will fix the volume of the oopses we are getting.)
Anton.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] 3.4.x: hrtimer: Provide clock_was_set_delayed()
This is a backport of f55a6faa384304c89cfef162768e88374d3312cb
clock_was_set() cannot be called from hard interrupt context because
it calls on_each_cpu().
For fixing the widely reported leap seconds issue it is necessary to
call it from hard interrupt context, i.e. the timer tick code, which
does the timekeeping updates.
Provide a new function which denotes it in the hrtimer cpu base
structure of the cpu on which it is called and raise the hrtimer
softirq. We then execute the clock_was_set() notificiation from
softirq context in run_hrtimer_softirq(). The hrtimer softirq is
rarely used, so polling the flag there is not a performance issue.
[ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
rid of all this ifdeffery ASAP ]
Signed-off-by: John Stultz
Reported-by: Jan Engelhardt
Reviewed-by: Ingo Molnar
Acked-by: Peter Zijlstra
Acked-by: Prarit Bhargava
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1341960205-56738-2-git-send-email-johns...@us.ibm.com
Signed-off-by: Thomas Gleixner
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/hrtimer.h |9 -
kernel/hrtimer.c| 20
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index fd0dc30..c9ec940 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -165,6 +165,7 @@ enum hrtimer_base_type {
* @lock: lock protecting the base and associated clock bases
* and timers
* @active_bases: Bitfield to mark bases with active timers
+ * @clock_was_set: Indicates that clock was set from irq context.
* @expires_next: absolute time of the next event which was scheduled
* via clock_set_next_event()
* @hres_active: State of high resolution mode
@@ -177,7 +178,8 @@ enum hrtimer_base_type {
*/
struct hrtimer_cpu_base {
raw_spinlock_t lock;
- unsigned long active_bases;
+ unsigned intactive_bases;
+ unsigned intclock_was_set;
#ifdef CONFIG_HIGH_RES_TIMERS
ktime_t expires_next;
int hres_active;
@@ -286,6 +288,8 @@ extern void hrtimer_peek_ahead_timers(void);
# define MONOTONIC_RES_NSECHIGH_RES_NSEC
# define KTIME_MONOTONIC_RES KTIME_HIGH_RES
+extern void clock_was_set_delayed(void);
+
#else
# define MONOTONIC_RES_NSECLOW_RES_NSEC
@@ -306,6 +310,9 @@ static inline int hrtimer_is_hres_active(struct hrtimer
*timer)
{
return 0;
}
+
+static inline void clock_was_set_delayed(void) { }
+
#endif
extern void clock_was_set(void);
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index ae34bf5..3c24fb2 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -717,6 +717,19 @@ static int hrtimer_switch_to_hres(void)
return 1;
}
+/*
+ * Called from timekeeping code to reprogramm the hrtimer interrupt
+ * device. If called from the timer interrupt context we defer it to
+ * softirq context.
+ */
+void clock_was_set_delayed(void)
+{
+ struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
+
+ cpu_base->clock_was_set = 1;
+ __raise_softirq_irqoff(HRTIMER_SOFTIRQ);
+}
+
#else
static inline int hrtimer_hres_active(void) { return 0; }
@@ -1395,6 +1408,13 @@ void hrtimer_peek_ahead_timers(void)
static void run_hrtimer_softirq(struct softirq_action *h)
{
+ struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
+
+ if (cpu_base->clock_was_set) {
+ cpu_base->clock_was_set = 0;
+ clock_was_set();
+ }
+
hrtimer_peek_ahead_timers();
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] 3.4.x: hrtimers: Move lock held region in hrtimer_interrupt()
From: Thomas Gleixner This is a backport of 196951e91262fccda81147d2bcf7fdab08668b40 We need to update the base offsets from this code and we need to do that under base->lock. Move the lock held region around the ktime_get() calls. The ktime_get() calls are going to be replaced with a function which gets the time and the offsets atomically. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Cc: sta...@vger.kernel.org Signed-off-by: John Stultz Link: http://lkml.kernel.org/r/1341960205-56738-6-git-send-email-johns...@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz --- kernel/hrtimer.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index 3c24fb2..8f320af 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -1263,11 +1263,10 @@ void hrtimer_interrupt(struct clock_event_device *dev) cpu_base->nr_events++; dev->next_event.tv64 = KTIME_MAX; + raw_spin_lock(&cpu_base->lock); entry_time = now = ktime_get(); retry: expires_next.tv64 = KTIME_MAX; - - raw_spin_lock(&cpu_base->lock); /* * We set expires_next to KTIME_MAX here with cpu_base->lock * held to prevent that a timer is enqueued in our queue via @@ -1344,6 +1343,7 @@ retry: * interrupt routine. We give it 3 attempts to avoid * overreacting on some spurious event. */ + raw_spin_lock(&cpu_base->lock); now = ktime_get(); cpu_base->nr_retries++; if (++retries < 3) @@ -1356,6 +1356,7 @@ retry: */ cpu_base->nr_hangs++; cpu_base->hang_detected = 1; + raw_spin_unlock(&cpu_base->lock); delta = ktime_sub(now, entry_time); if (delta.tv64 > cpu_base->max_hang_time.tv64) cpu_base->max_hang_time = delta; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] 3.4.x: timekeeping: Maintain ktime_t based offsets for hrtimers
From: Thomas Gleixner
This is a backport of 5b9fe759a678e05be4937ddf03d50e950207c1c0
We need to update the hrtimer clock offsets from the hrtimer interrupt
context. To avoid conversions from timespec to ktime_t maintain a
ktime_t based representation of those offsets in the timekeeper. This
puts the conversion overhead into the code which updates the
underlying offsets and provides fast accessible values in the hrtimer
interrupt.
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz
Reviewed-by: Ingo Molnar
Acked-by: Peter Zijlstra
Acked-by: Prarit Bhargava
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1341960205-56738-4-git-send-email-johns...@us.ibm.com
Signed-off-by: Thomas Gleixner
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Linux Kernel
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 9588f0c..615ec8d 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -70,6 +70,12 @@ struct timekeeper {
/* The raw monotonic time for the CLOCK_MONOTONIC_RAW posix clock. */
struct timespec raw_time;
+ /* Offset clock monotonic -> clock realtime */
+ ktime_t offs_real;
+
+ /* Offset clock monotonic -> clock boottime */
+ ktime_t offs_boot;
+
/* Seqlock for all timekeeper values */
seqlock_t lock;
};
@@ -172,6 +178,14 @@ static inline s64 timekeeping_get_ns_raw(void)
return clocksource_cyc2ns(cycle_delta, clock->mult, clock->shift);
}
+static void update_rt_offset(void)
+{
+ struct timespec tmp, *wtm = &timekeeper.wall_to_monotonic;
+
+ set_normalized_timespec(&tmp, -wtm->tv_sec, -wtm->tv_nsec);
+ timekeeper.offs_real = timespec_to_ktime(tmp);
+}
+
/* must hold write on timekeeper.lock */
static void timekeeping_update(bool clearntp)
{
@@ -179,6 +193,7 @@ static void timekeeping_update(bool clearntp)
timekeeper.ntp_error = 0;
ntp_clear();
}
+ update_rt_offset();
update_vsyscall(&timekeeper.xtime, &timekeeper.wall_to_monotonic,
timekeeper.clock, timekeeper.mult);
}
@@ -606,6 +621,7 @@ void __init timekeeping_init(void)
}
set_normalized_timespec(&timekeeper.wall_to_monotonic,
-boot.tv_sec, -boot.tv_nsec);
+ update_rt_offset();
timekeeper.total_sleep_time.tv_sec = 0;
timekeeper.total_sleep_time.tv_nsec = 0;
write_sequnlock_irqrestore(&timekeeper.lock, flags);
@@ -614,6 +630,12 @@ void __init timekeeping_init(void)
/* time in seconds when suspend began */
static struct timespec timekeeping_suspend_time;
+static void update_sleep_time(struct timespec t)
+{
+ timekeeper.total_sleep_time = t;
+ timekeeper.offs_boot = timespec_to_ktime(t);
+}
+
/**
* __timekeeping_inject_sleeptime - Internal function to add sleep interval
* @delta: pointer to a timespec delta value
@@ -632,8 +654,7 @@ static void __timekeeping_inject_sleeptime(struct timespec
*delta)
timekeeper.xtime = timespec_add(timekeeper.xtime, *delta);
timekeeper.wall_to_monotonic =
timespec_sub(timekeeper.wall_to_monotonic, *delta);
- timekeeper.total_sleep_time = timespec_add(
- timekeeper.total_sleep_time, *delta);
+ update_sleep_time(timespec_add(timekeeper.total_sleep_time, *delta));
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] 3.4.x: timekeeping: Add missing update call in timekeeping_resume()
From: Thomas Gleixner This is a backport of 3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0 The leap second rework unearthed another issue of inconsistent data. On timekeeping_resume() the timekeeper data is updated, but nothing calls timekeeping_update(), so now the update code in the timer interrupt sees stale values. This has been the case before those changes, but then the timer interrupt was using stale data as well so this went unnoticed for quite some time. Add the missing update call, so all the data is consistent everywhere. Reported-by: Andreas Schwab Reported-and-tested-by: "Rafael J. Wysocki" Reported-and-tested-by: Martin Steigerwald Cc: LKML Cc: Linux PM list Cc: John Stultz Cc: Ingo Molnar Cc: Peter Zijlstra , Cc: Prarit Bhargava Cc: sta...@vger.kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: John Stultz Signed-off-by: Linus Torvalds Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz --- kernel/time/timekeeping.c |1 + 1 file changed, 1 insertion(+) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 62e12c3..7c50de8 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -719,6 +719,7 @@ static void timekeeping_resume(void) timekeeper.clock->cycle_last = timekeeper.clock->read(timekeeper.clock); timekeeper.ntp_error = 0; timekeeping_suspended = 0; + timekeeping_update(false); write_sequnlock_irqrestore(&timekeeper.lock, flags); touch_softlockup_watchdog(); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] 3.4-stable: Fix for leapsecond caused hrtimer/futex issue
Here is backport of the leapsecond fixes to 3.4-stable. These are very straight forward, and backported to 3.4.x with no collisions or changes. This patchset resolve the early hrtimer/futex expiration issue widely seen after the June 30th leapsecond. I've booted and tested this patchset on two boxes and run through a number of leapsecond related stress tests. However, additional testing and review would be appreciated. The original commits backported in this set are: f55a6faa384304c89cfef162768e88374d3312cbhrtimer: Provide clock_was_set_delayed() 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51timekeeping: Fix leapsecond triggered load spike issue 5b9fe759a678e05be4937ddf03d50e950207c1c0timekeeping: Maintain ktime_t based offsets for hrtimers 196951e91262fccda81147d2bcf7fdab08668b40hrtimers: Move lock held region in hrtimer_interrupt() f6c06abfb3972ad4914cef57d8348fcb2932bc3btimekeeping: Provide hrtimer update function 5baefd6d84163443215f4a99f6a20f054ef11236hrtimer: Update hrtimer base offsets each hrtimer_interrupt 3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0timekeeping: Add missing update call in timekeeping_resume() I've already done backports to all the stable kernels to 2.6.32, and will be sending them out shortly. Please let me know if you have any comments or feedback. thanks -john Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel John Stultz (3): 3.4.x: hrtimer: Provide clock_was_set_delayed() 3.4.x: timekeeping: Fix leapsecond triggered load spike issue 3.4.x: hrtimer: Update hrtimer base offsets each hrtimer_interrupt Thomas Gleixner (4): 3.4.x: timekeeping: Maintain ktime_t based offsets for hrtimers 3.4.x: hrtimers: Move lock held region in hrtimer_interrupt() 3.4.x: timekeeping: Provide hrtimer update function 3.4.x: timekeeping: Add missing update call in timekeeping_resume() include/linux/hrtimer.h | 10 ++- kernel/hrtimer.c | 53 + kernel/time/timekeeping.c | 64 +++-- 3 files changed, 108 insertions(+), 19 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] 3.4.x: timekeeping: Provide hrtimer update function
From: Thomas Gleixner
This is a backport of f6c06abfb3972ad4914cef57d8348fcb2932bc3b
To finally fix the infamous leap second issue and other race windows
caused by functions which change the offsets between the various time
bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
function which atomically gets the current monotonic time and updates
the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
overhead. The previous patch which provides ktime_t offsets allows us
to make this function almost as cheap as ktime_get() which is going to
be replaced in hrtimer_interrupt().
Signed-off-by: Thomas Gleixner
Reviewed-by: Ingo Molnar
Acked-by: Peter Zijlstra
Acked-by: Prarit Bhargava
Cc: sta...@vger.kernel.org
Signed-off-by: John Stultz
Link:
http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johns...@us.ibm.com
Signed-off-by: Thomas Gleixner
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/hrtimer.h |1 +
kernel/time/timekeeping.c | 34 ++
2 files changed, 35 insertions(+)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index c9ec940..cc07d27 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -327,6 +327,7 @@ extern ktime_t ktime_get(void);
extern ktime_t ktime_get_real(void);
extern ktime_t ktime_get_boottime(void);
extern ktime_t ktime_get_monotonic_offset(void);
+extern ktime_t ktime_get_update_offsets(ktime_t *offs_real, ktime_t
*offs_boot);
DECLARE_PER_CPU(struct tick_device, tick_cpu_device);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 615ec8d..62e12c3 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1273,6 +1273,40 @@ void get_xtime_and_monotonic_and_sleep_offset(struct
timespec *xtim,
} while (read_seqretry(&timekeeper.lock, seq));
}
+#ifdef CONFIG_HIGH_RES_TIMERS
+/**
+ * ktime_get_update_offsets - hrtimer helper
+ * @offs_real: pointer to storage for monotonic -> realtime offset
+ * @offs_boot: pointer to storage for monotonic -> boottime offset
+ *
+ * Returns current monotonic time and updates the offsets
+ * Called from hrtimer_interupt() or retrigger_next_event()
+ */
+ktime_t ktime_get_update_offsets(ktime_t *offs_real, ktime_t *offs_boot)
+{
+ ktime_t now;
+ unsigned int seq;
+ u64 secs, nsecs;
+
+ do {
+ seq = read_seqbegin(&timekeeper.lock);
+
+ secs = timekeeper.xtime.tv_sec;
+ nsecs = timekeeper.xtime.tv_nsec;
+ nsecs += timekeeping_get_ns();
+ /* If arch requires, add in gettimeoffset() */
+ nsecs += arch_gettimeoffset();
+
+ *offs_real = timekeeper.offs_real;
+ *offs_boot = timekeeper.offs_boot;
+ } while (read_seqretry(&timekeeper.lock, seq));
+
+ now = ktime_add_ns(ktime_set(secs, 0), nsecs);
+ now = ktime_sub(now, *offs_real);
+ return now;
+}
+#endif
+
/**
* ktime_get_monotonic_offset() - get wall_to_monotonic in ktime_t format
*/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] 3.4.x: timekeeping: Fix leapsecond triggered load spike issue
This is a backport of 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51 The timekeeping code misses an update of the hrtimer subsystem after a leap second happened. Due to that timers based on CLOCK_REALTIME are either expiring a second early or late depending on whether a leap second has been inserted or deleted until an operation is initiated which causes that update. Unless the update happens by some other means this discrepancy between the timekeeping and the hrtimer data stays forever and timers are expired either early or late. The reported immediate workaround - $ data -s "`date`" - is causing a call to clock_was_set() which updates the hrtimer data structures. See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix Add the missing clock_was_set() call to update_wall_time() in case of a leap second event. The actual update is deferred to softirq context as the necessary smp function call cannot be invoked from hard interrupt context. Signed-off-by: John Stultz Reported-by: Jan Engelhardt Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra Acked-by: Prarit Bhargava Cc: sta...@vger.kernel.org Link: http://lkml.kernel.org/r/1341960205-56738-3-git-send-email-johns...@us.ibm.com Signed-off-by: Thomas Gleixner Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz --- kernel/time/timekeeping.c |4 1 file changed, 4 insertions(+) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index d42574df..9588f0c 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -965,6 +965,8 @@ static cycle_t logarithmic_accumulation(cycle_t offset, int shift) leap = second_overflow(timekeeper.xtime.tv_sec); timekeeper.xtime.tv_sec += leap; timekeeper.wall_to_monotonic.tv_sec -= leap; + if (leap) + clock_was_set_delayed(); } /* Accumulate raw time */ @@ -1081,6 +1083,8 @@ static void update_wall_time(void) leap = second_overflow(timekeeper.xtime.tv_sec); timekeeper.xtime.tv_sec += leap; timekeeper.wall_to_monotonic.tv_sec -= leap; + if (leap) + clock_was_set_delayed(); } timekeeping_update(false); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 1/2] MFD: twl6040: Fix revision information
Hello Peter,
On 7/16/2012 3:19 PM, Peter Ujfalusi wrote:
twl6040 ES1.1 and ES1.2 have the same revid (0x01).
ES1.3 of twl6040 REVID is 0x02.
Signed-off-by: Peter Ujfalusi
---
include/linux/mfd/twl6040.h |4 ++--
sound/soc/codecs/twl6040.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index 6659487..e002097 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -161,8 +161,8 @@
#define TWL6040_CELLS 2
#define TWL6040_REV_ES1_0 0x00
-#define TWL6040_REV_ES1_1 0x01
-#define TWL6040_REV_ES1_2 0x02
+#define TWL6040_REV_ES1_1 0x01 /* Rev ES1.1 and ES1.2 */
+#define TWL6040_REV_ES1_3 0x02
#define TWL6040_IRQ_TH0
#define TWL6040_IRQ_PLUG 1
diff --git a/sound/soc/codecs/twl6040.c b/sound/soc/codecs/twl6040.c
index a36e9fc..2786de2 100644
--- a/sound/soc/codecs/twl6040.c
+++ b/sound/soc/codecs/twl6040.c
@@ -653,7 +653,7 @@ int twl6040_get_hs_step_size(struct snd_soc_codec *codec)
{
struct twl6040 *twl6040 = codec->control_data;
- if (twl6040_get_revid(twl6040)< TWL6040_REV_ES1_2)
+ if (twl6040_get_revid(twl6040)< TWL6040_REV_ES1_3)
Instead of doing this change why not you take a #define for revision and
do
if (twl6040_get_revid(twl6040)< TWL6040_REV)
~Rajeev
/* For ES under ES_1.3 HS step is 2 mV */
return 2;
else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH mmotm] memcg: further prevent OOM with too many dirty pages
On Mon 16-07-12 21:52:51, Hugh Dickins wrote: > On Mon, 16 Jul 2012, Michal Hocko wrote: > > On Mon 16-07-12 01:35:34, Hugh Dickins wrote: > > > But even so, the test still OOMs sometimes: when originally testing > > > on 3.5-rc6, it OOMed about one time in five or ten; when testing > > > just now on 3.5-rc6-mm1, it OOMed on the first iteration. > > > > > > This residual problem comes from an accumulation of pages under > > > ordinary writeback, not marked PageReclaim, so rightly not causing > > > the memcg check to wait on their writeback: these too can prevent > > > shrink_page_list() from freeing any pages, so many times that memcg > > > reclaim fails and OOMs. > > > > I guess you managed to trigger this with 20M limit, right? > > That's right. > > > I have tested > > with different group sizes but the writeback didn't trigger for most of > > them and all the dirty data were flushed from the reclaim. > > I didn't examine writeback stats to confirm, but I guess that just > occasionally it managed to come in and do enough work to confound us. > > > Have you used any special setting the dirty ratio? > > No, I wasn't imaginative enough to try that. > > > Or was it with xfs (IIUC that one > > does ignore writeback from the direct reclaim completely). > > No, just ext4 at that point. > > I have since tested the final patch with ext4, ext3 (by ext3 driver > and by ext4 driver), ext2 (by ext2 driver and by ext4 driver), xfs, > btrfs, vfat, tmpfs (with swap on the USB stick) and block device: > about an hour on each, no surprises, all okay. > > But I didn't experiment beyond the 20M memcg. Great coverage anyway. Thanks a lot Hugh! > > Hugh -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch -next] ext4: locking issue on error path
We recently changed how the locking worked here, but this error path was
missed.
Signed-off-by: Dan Carpenter
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 8c84070..2728fb7 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3031,8 +3031,10 @@ static ssize_t ext4_ext_direct_IO(int rw, struct kiocb
*iocb,
if (!is_sync_kiocb(iocb)) {
ext4_io_end_t *io_end =
ext4_init_io_end(inode, GFP_NOFS);
- if (!io_end)
- return -ENOMEM;
+ if (!io_end) {
+ ret = -ENOMEM;
+ goto retake_lock;
+ }
io_end->flag |= EXT4_IO_END_DIRECT;
iocb->private = io_end;
/*
@@ -3094,6 +3096,7 @@ static ssize_t ext4_ext_direct_IO(int rw, struct kiocb
*iocb,
ext4_clear_inode_state(inode, EXT4_STATE_DIO_UNWRITTEN);
}
+retake_lock:
/* take i_mutex locking again if we do a ovewrite dio */
if (overwrite) {
up_read(&EXT4_I(inode)->i_data_sem);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] vfs: Make sys_sync writeout also block device inodes
Hi Jan,
I got this error for !CONFIG_BLOCK builds:
fs/sync.c:110:2: error: implicit declaration of function 'iterate_bdevs'
[-Werror=implicit-function-declaration]
Thanks,
Fengguang
On Tue, Jul 03, 2012 at 04:45:32PM +0200, Jan Kara wrote:
> In case block device does not have filesystem mounted on it, sys_sync will
> just
> ignore it and doesn't writeout its dirty pages. This is because writeback code
> avoids writing inodes from superblock without backing device and
> blockdev_superblock is such a superblock. Since it's unexpected that sync
> doesn't writeout dirty data for block devices be nice to users and change the
> behavior to do so. So now we iterate over all block devices on blockdev_super
> instead of iterating over all superblocks when syncing block devices.
>
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Jan Kara
> ---
> fs/sync.c | 18 +++---
> 1 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/fs/sync.c b/fs/sync.c
> index 867bf78..ea6e818 100644
> --- a/fs/sync.c
> +++ b/fs/sync.c
> @@ -85,10 +85,14 @@ static void sync_fs_one_sb(struct super_block *sb, void
> *arg)
> sb->s_op->sync_fs(sb, *(int *)arg);
> }
>
> -static void sync_blkdev_one_sb(struct super_block *sb, void *arg)
> +static void flush_one_bdev(struct block_device *bdev, void *arg)
> {
> - if (!(sb->s_flags & MS_RDONLY))
> - __sync_blockdev(sb->s_bdev, *(int *)arg);
> + __sync_blockdev(bdev, 0);
> +}
> +
> +static void sync_one_bdev(struct block_device *bdev, void *arg)
> +{
> + sync_blockdev(bdev);
> }
>
> /*
> @@ -102,10 +106,10 @@ SYSCALL_DEFINE0(sync)
> wakeup_flusher_threads(0, WB_REASON_SYNC);
> iterate_supers(writeback_inodes_one_sb, NULL);
> iterate_supers(sync_fs_one_sb, &nowait);
> - iterate_supers(sync_blkdev_one_sb, &nowait);
> + iterate_bdevs(flush_one_bdev, NULL);
> iterate_supers(sync_inodes_one_sb, NULL);
> iterate_supers(sync_fs_one_sb, &wait);
> - iterate_supers(sync_blkdev_one_sb, &wait);
> + iterate_bdevs(sync_one_bdev, NULL);
> if (unlikely(laptop_mode))
> laptop_sync_completion();
> return 0;
> @@ -121,10 +125,10 @@ static void do_sync_work(struct work_struct *work)
>*/
> iterate_supers(sync_inodes_one_sb, &nowait);
> iterate_supers(sync_fs_one_sb, &nowait);
> - iterate_supers(sync_blkdev_one_sb, &nowait);
> + iterate_bdevs(flush_one_bdev, NULL);
> iterate_supers(sync_inodes_one_sb, &nowait);
> iterate_supers(sync_fs_one_sb, &nowait);
> - iterate_supers(sync_blkdev_one_sb, &nowait);
> + iterate_bdevs(flush_one_bdev, NULL);
> printk("Emergency Sync complete\n");
> kfree(work);
> }
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gigaset: silence GCC warning for unused 'format_ie'
From: Paul Bolle Date: Sun, 15 Jul 2012 11:11:55 +0200 > Building Gigaset's CAPI support without Gigaset's debugging enabled > triggers this GCC warning: > 'format_ie' defined but not used [-Wunused-function] > > Silence this warning by wrapping format_ie() in an "#ifdef > CONFIG_GIGASET_DEBUG" and "#endif" pair. > > Signed-off-by: Paul Bolle Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irda: Fix typo in irda
From: Masanari Iida Date: Sat, 14 Jul 2012 02:22:47 +0900 > Correct spelling typo in irda. > > Signed-off-by: Masanari Iida Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: reflect actual changes in IEEE 802.15.4 maintainership
From: Dmitry Eremin-Solenikov Date: Sat, 14 Jul 2012 10:15:34 +0400 > As the life flows, developers priorities shifts a bit. Reflect actual > changes in the maintainership of IEEE 802.15.4 code: Sergey mostly > stopped cared about this piece of code. Most of the work recently was > done by Alexander, so put him to the MAINTAINERS file to reflect his > status and to ease the life of respective patches. > > Also add new net/mac802154/ directory to the list of maintained files. > > Signed-off-by: Dmitry Eremin-Solenikov > Cc: Alexander Smirnov Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] CMA and DMA-mapping fixes for v3.5-rc7
Hi Linus, I woukd like to ask you again for pulling another set of minor fixups for recently merged Contiguous Memory Allocator and ARM DMA-mapping changes. Those patches fix mysterious crashes on systems with CMA and Himem enabled as well as some corner cases caused by typical off-by-one bug. I'm sorry for a delay in sending this pull request which is caused by my vacations. The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) with the top-most commit 46c87852e99cf8ce97e207b11cde19085837e39c ARM: dma-mapping: modify condition check while freeing pages are available in the git repository at: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git fixes-for-linus Marek Szyprowski (1): mm: cma: fix condition check when setting global cma area Prathyush K (1): ARM: dma-mapping: modify condition check while freeing pages Rabin Vincent (1): mm: cma: don't replace lowmem pages with highmem arch/arm/mm/dma-mapping.c|4 ++-- include/asm-generic/dma-contiguous.h |2 +- mm/page_alloc.c |7 ++- 3 files changed, 9 insertions(+), 4 deletions(-) Thanks! Best regards Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] tmpfs: revert SEEK_DATA and SEEK_HOLE
On 07/16/2012 05:28 PM, Hugh Dickins wrote: > On Thu, 12 Jul 2012, Jeff Liu wrote: >> On 07/12/2012 07:01 AM, Dave Chinner wrote: >>> On Wed, Jul 11, 2012 at 11:55:34AM -0700, Hugh Dickins wrote: But your vote would count for a lot more if you know of some app which would really benefit from this functionality in tmpfs: I've heard of none. >>> >>> So what? I've heard of no apps that use this functionality on XFS, >>> either, but I have heard of a lot of people asking for it to be >>> implemented over the past couple of years so they can use it. >>> There's been patches written to make coreutils (cp) make use of it >>> instead of parsing FIEMAP output to find holes, though I don't know >>> if that's gone beyond more than "here's some patches"... >> >> Yes, for apps, cp(1) will make use of it to replace the old FIEMAP for >> efficient sparse file copy. >> I have implemented an extent-scan module to coreutils a few years ago, >> http://fossies.org/dox/coreutils-8.17/extent-scan_8c_source.html > > Thanks for confirming Dave's pointer to cp. > > Of course, tmpfs has never supported FIBMAP or FIEMAP; > but SEEK_DATA and SEEK_HOLE do fit it much more naturally. > >> >> It does extent scan through FIEMAP, however, SEEK_DATA/SEEK_HOLE is more >> convenient and easy to use >> considering the call interface. So FIEMAP will be replaced by SEEK_XXX once >> it got supported by EXT4. >> >> Moreover, I have discussed with Jim who is the coreutils maintainer >> previously, He would like to post >> extent-scan module to Gnulib so that other GNU utilities which are relied on >> Gnulib might be a potential >> user of it, at least, GNU tar will definitely need it for sparse file backup. > > Thanks for the info. I confess I'm not hugely swayed by cp and sparse > file archive arguments - I doubt many people care, and I doubt those who > do care are using tmpfs for them. > > But my doubts are just ignorance. I was hoping to hear, not that we have > tools to copy sparse files efficiently (umm, over the network?), but > what apps are actually working live with those sparse files on tmpfs, > and now need to seek around them. Some math or physics applications? > >>> >>> Besides, given that you can punch holes in tmpfs files, it seems >>> strange to then say "we don't need a method of skipping holes to >>> find data quickly" >> >> So its deserve to keep this feature working on tmpfs considering hole punch. >> :) > > Well, thank you, as I said earlier I am on both sides of the argument. > (And feel uncomfortably like a prima donna waiting in the wings until > the audience has shouted long enough for the encore.) Oh, sorry, I missed you response to Dave before. > > It's now taken out of 3.5, but we can bring it back when there's more > demand. Yep. :) Thanks, -Jeff > Your extent-scan is itself waiting for ext4 to support it: > maybe get noisy at me when that's imminent. > > Hugh > >> >> Thanks, >> -Jeff >> >>> >>> Besides, seek-hole/data is still shiny new and lots of developers >>> aren't even aware of it's presence in recent kernels. Removing new >>> functionality saying "no-one is using it" is like smashing the egg >>> before the chicken hatches (or is it cutting of the chickes's head >>> before it lays the egg?). >>> >>> Cheers, >>> >>> Dave. > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH REBASE] regulator: tps65910: set input_supply on desc unconditionally
Set the supply_name in the regulator descriptor unconditionally
and make this parameter as required parameter in the device
node for successfully registration of the regulator.
Signed-off-by: Laxman Dewangan
---
The changes are based on on discussion on patch
[PATCH 1/3] ARM: dt: tegra: seaboard: add regulators
on which the input supply name should be require in DT case and
unconditionally set on the desc.supply_name.
Although the support was accepted earlier but as per discussion,
it was not so good and hence this is the change.
Becasue no-one is using this device as of now in dt file, it is safe
to change now and provide guidance to the new user of this device.
There is problem in apply patch. Rebased against Mark's topic/drivers
and sending.
Documentation/devicetree/bindings/mfd/tps65910.txt | 33 +--
drivers/regulator/tps65910-regulator.c | 11 +--
include/linux/mfd/tps65910.h |2 -
3 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt
b/Documentation/devicetree/bindings/mfd/tps65910.txt
index 31be5a3..d2802d4 100644
--- a/Documentation/devicetree/bindings/mfd/tps65910.txt
+++ b/Documentation/devicetree/bindings/mfd/tps65910.txt
@@ -25,17 +25,12 @@ Required properties:
tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
ldo6, ldo7, ldo8
-Optional properties:
-- ti,vmbch-threshold: (tps65911) main battery charged threshold
- comparator. (see VMBCH_VSEL in TPS65910 datasheet)
-- ti,vmbch2-threshold: (tps65911) main battery discharged threshold
- comparator. (see VMBCH_VSEL in TPS65910 datasheet)
-- ti,en-gpio-sleep: enable sleep control for gpios
- There should be 9 entries here, one for each gpio.
- xxx-supply: Input voltage supply regulator.
- Missing of these properties will be assume as there is no supply regulator
- for that input pins and always powered on.
- The valid input supply properties are:
+ These entries are require if regulators are enabled for a device. Missing of
these
+ properties can cause the regulator registration fails.
+ If some of input supply is powered through battery or always-on supply then
+ also it is require to have these parameters with proper node handle of always
+ on power supply.
tps65910:
vcc1-supply: VDD1 input.
vcc2-supply: VDD2 input.
@@ -55,6 +50,16 @@ Optional properties:
vcc7-supply: VRTC input.
vccio-supply: VIO input.
+Optional properties:
+- ti,vmbch-threshold: (tps65911) main battery charged threshold
+ comparator. (see VMBCH_VSEL in TPS65910 datasheet)
+- ti,vmbch2-threshold: (tps65911) main battery discharged threshold
+ comparator. (see VMBCH_VSEL in TPS65910 datasheet)
+- ti,en-ck32k-xtal: enable external 32-kHz crystal oscillator (see CK32K_CTRL
+ in TPS6591X datasheet)
+- ti,en-gpio-sleep: enable sleep control for gpios
+ There should be 9 entries here, one for each gpio.
+
Regulator Optional properties:
- ti,regulator-ext-sleep-control: enable external sleep
control through external inputs [0 (not enabled), 1 (EN1), 2 (EN2) or 4(EN3)]
@@ -79,8 +84,14 @@ Example:
ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>;
- vcc7-supply = <®_parent>;
vcc1-supply = <®_parent>;
+ vcc2-supply = <&some_reg>;
+ vcc3-supply = <...>;
+ vcc4-supply = <...>;
+ vcc5-supply = <...>;
+ vcc6-supply = <...>;
+ vcc7-supply = <...>;
+ vccio-supply = <...>;
regulators {
#address-cells = <1>;
diff --git a/drivers/regulator/tps65910-regulator.c
b/drivers/regulator/tps65910-regulator.c
index d2ba066..793adda 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -1001,9 +1001,6 @@ static struct tps65910_board *tps65910_parse_dt_reg_data(
*tps65910_reg_matches = matches;
for (idx = 0; idx < count; idx++) {
- struct tps_info *info = matches[idx].driver_data;
- char in_supply[32]; /* 32 is max size of property name */
-
if (!matches[idx].init_data || !matches[idx].of_node)
continue;
@@ -1015,12 +1012,6 @@ static struct tps65910_board *tps65910_parse_dt_reg_data(
if (!ret)
pmic_plat_data->regulator_ext_sleep_control[idx] = prop;
- if (info->vin_name) {
- snprintf(in_supply, 32, "%s-supply", info->vin_name);
- if (of_find_property(np, in_supply, 0))
- pmic_plat_data->input_supply[idx] =
- info->vin_name;
- }
}
return pmic_plat_data;
@@ -1123,7 +1114,7 @@ static __devinit int tps65910_probe(struct
platform_device *pdev)
Re: [PATCH V2 3/4] [SCSI] ufs: Add Platform glue driver for ufshcd
On Mon, Jul 16, 2012 at 7:19 PM, Namjae Jeon wrote:
> Hi Vinayak.
>> + * ufshcd_pltfrm_remove - remove platform driver routine
>> + * @pdev: pointer to platform device handle
>> + *
>> + * Returns 0 on success, non-zero value on failure
>> + */
>> +static int __devexit ufshcd_pltfrm_remove(struct platform_device *pdev)
>> +{
>> + struct resource *mem_res;
>> + struct resource *irq_res;
>> + resource_size_t mem_size;
>> + struct ufs_hba *hba = platform_get_drvdata(pdev);
>> +
>> + ufshcd_remove(hba);
>> + irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> + if (!irq_res)
>> + dev_err(&pdev->dev, "ufshcd: IRQ resource not available\n");
>> + free_irq(irq_res->start, hba);
> Is there no possibility of null pointer dereferencing error ?(irq_res->start)
> I think that free_irq should be not called if irq_res is NULL.
I agree, I have overlooked at this logic, the free_irq should have
been in the else
part of this section. I will make the modification in the next version
of patches.
>> + mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> Looks mem_res is also same with upper case.
> Thanks.
>> + mem_size = resource_size(mem_res);
>> + release_mem_region(mem_res->start, mem_size);
>> + platform_set_drvdata(pdev, NULL);
>> + return 0;
>> +}
>> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] gpio/omap: add *remove* callback in platform_driver
On Mon, Jul 16, 2012 at 10:40 PM, Kevin Hilman wrote: > > Linus Walleij writes: > > > On Thu, Jul 12, 2012 at 7:48 PM, Kevin Hilman wrote: > > > >> In the case of OMAP GPIO, unless it's an obvious fix, I would recommend > >> you wait at least until you see some acks/tested tags from any of > >> > >> - Santosh Shilimkar > >> - Rajendra Nayak > >> - Benoit Cousson > >> > >> or Tony, Paul or myself. > > > > Instead of trying to store this information in my and Grants brains and > > us forgetting it, what about patching MAINTAINERS to reflect the fact > > instead? That's better I think, plus I use that file a lot. > > > >> For major series, I have been collecting/queueing them for Grant after > >> ensuring they have been well reviewed and well tested (although I am > >> eagerly hoping to hand off this role to someone else.) > > > > Listing it under your GIT tree in MAINTAINERS for this driver will make > > this work better I think. > > > > One path for OMAP GPIO patches, simple. It's obviously the > > ambiguity that cause the trouble. Then you can also decide > > on each cycle whether to send these to GPIO or ARM SoC > > etc. > > Yeah, I understand the process, but I've been avoiding doing that > because, well, I don't want the job. I have been trying to get someone > else at TI to maintain this driver, but have not been successful. > > So, until that happens, feel free to queue up the patch below. > > Santosh, note that I've put you as co-maintainer of this driver. > No problem Kevin. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] net: cgroup: fix access the unallocated memory in netprio cgroup
From: Neil Horman Date: Thu, 12 Jul 2012 06:56:11 -0400 > On Thu, Jul 12, 2012 at 03:50:15PM +0800, Gao feng wrote: >> there are some out of bound accesses in netprio cgroup. ... >> Signed-off-by: Gao feng > > Acked-by: Neil Horman > Applied to 'net', thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net,1/1] hyperv: Add support for setting MAC from within guests
From: Haiyang Zhang Date: Tue, 10 Jul 2012 10:19:22 -0700 > This adds support for setting synthetic NIC MAC address from within Linux > guests. Before using this feature, the option "spoofing of MAC address" > should be enabled at the Hyper-V manager / Settings of the synthetic > NIC. > > Thanks to Kin Cho for the initial implementation and > tests. And, thanks to Long Li for the debugging > works. > > Reported-and-tested-by: Kin Cho > Reported-by: Long Li > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ALSA: hda - Add new GPU codec ID to snd-hda
At Mon, 16 Jul 2012 17:10:04 -0700,
Aaron Plattner wrote:
>
> Vendor ID 0x10de0051 is used by a yet-to-be-named GPU chip.
>
> Signed-off-by: Aaron Plattner
> Acked-by: Andy Ritger
> Reviewed-by: Daniel Dadap
Applied now. Thanks.
Takashi
> ---
> sound/pci/hda/patch_hdmi.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index ad319d4..4efe741 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -1902,6 +1902,7 @@ static const struct hda_codec_preset
> snd_hda_preset_hdmi[] = {
> { .id = 0x10de0042, .name = "GPU 42 HDMI/DP",.patch =
> patch_generic_hdmi },
> { .id = 0x10de0043, .name = "GPU 43 HDMI/DP",.patch =
> patch_generic_hdmi },
> { .id = 0x10de0044, .name = "GPU 44 HDMI/DP",.patch =
> patch_generic_hdmi },
> +{ .id = 0x10de0051, .name = "GPU 51 HDMI/DP",.patch =
> patch_generic_hdmi },
> { .id = 0x10de0067, .name = "MCP67 HDMI",.patch = patch_nvhdmi_2ch },
> { .id = 0x10de8001, .name = "MCP73 HDMI",.patch = patch_nvhdmi_2ch },
> { .id = 0x80860054, .name = "IbexPeak HDMI", .patch = patch_generic_hdmi },
> @@ -1948,6 +1949,7 @@ MODULE_ALIAS("snd-hda-codec-id:10de0041");
> MODULE_ALIAS("snd-hda-codec-id:10de0042");
> MODULE_ALIAS("snd-hda-codec-id:10de0043");
> MODULE_ALIAS("snd-hda-codec-id:10de0044");
> +MODULE_ALIAS("snd-hda-codec-id:10de0051");
> MODULE_ALIAS("snd-hda-codec-id:10de0067");
> MODULE_ALIAS("snd-hda-codec-id:10de8001");
> MODULE_ALIAS("snd-hda-codec-id:17e80047");
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for July 17
Hi all, Changes since 20120716: The vfs tree lost its build failure. The l2-mtd tree gained a conflict against the mtd tree. The battery tree tree lost its build failure. The regulator tree gained conflicts against the mfd tree. The tty tree lost its build failure but gained another, so I used the version from next-20120712. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. The akpm tree lost a few patches that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 197 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (e5254a6 Merge branch 'gma500' (Alan's GMA patches)) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (ff081e0 ARM: 7457/1: smp: Fix suspicious RCU originating from cpu_die()) Merging m68k-current/for-linus (d8ce726 m68k: Use generic strncpy_from_user(), strlen_user(), and strnlen_user()) Merging powerpc-merge/merge (50fb31c tty/hvc_opal: Fix debug function name) Merging sparc/master (d55de60 sparc64: remove unused function straddles_64bit_va_hole()) Merging net/master (310e158 net: respect GFP_DMA in __netdev_alloc_skb()) Merging sound-current/for-linus (68e67f4 ALSA: snd-usb: move calls to usb_set_interface) Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging wireless/master (8a70e7f NFC: NCI module license 'unspecified' taints kernel) Merging driver-core.current/driver-core-linus (5becfb1 kmsg: merge continuation records while printing) Merging tty.current/tty-linus (84a1caf Linux 3.5-rc7) Merging usb.current/usb-linus (84a1caf Linux 3.5-rc7) Merging staging.current/staging-linus (6887a41 Linux 3.5-rc5) Merging char-misc.current/char-misc-linus (84a1caf Linux 3.5-rc7) Merging input-current/for-linus (e76b8ee Input: xpad - add Andamiro Pump It Up pad) Merging md-current/for-linus (2d4f4f3 md/raid1: fix use-after-free bug in RAID1 data-check code.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c475c06 hwrng: atmel-rng - fix data valid check) Merging ide/master (39a50b4 Merge branch 'hfsplus') Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/for-next (dea2ea3 Merge branches 'audit', 'delay', 'dmaengine',
Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Joe Perches
Date: Thu, 12 Jul 2012 22:33:04 -0700
> net-next commit ad7eee98be ("etherdevice: introduce eth_broadcast_addr")
> added a new style API. Rename random_ether_addr to eth_random_addr to
> create some API symmetry.
Series applied, thanks Joe.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 13:32 +0800, Jovi Zhang wrote: > On Tue, Jul 17, 2012 at 1:07 PM, Joe Perches wrote: > > On Tue, 2012-07-17 at 00:25 -0400, Steven Rostedt wrote: [] > >> Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > >> not a module. > > > > It depends on the Makefile. > > > > scripts/Makefile.lib:# $(modname_flags) #defines KBUILD_MODNAME as the name > > of the module it will > > scripts/Makefile.lib-# end up in (or would, if it gets compiled in) > > scripts/Makefile.lib-# Note: Files that end up in two or more modules are > > compiled without the > > scripts/Makefile.lib:# KBUILD_MODNAME definition. The reason is that > > any made-up name would > > scripts/Makefile.lib-# differ in different configs. > > scripts/Makefile.lib-name-fix = $(subst $(comma),_,$(subst -,_,$1)) > > scripts/Makefile.lib-basename_flags = -D"KBUILD_BASENAME=KBUILD_STR($(call > > name-fix,$(basetarget)))" > > scripts/Makefile.lib-modname_flags = $(if $(filter 1,$(words $(modname))),\ > > scripts/Makefile.lib: -D"KBUILD_MODNAME=KBUILD_STR($(call > > name-fix,$(modname)))") > > > Hmm, that would make sense, get subsystem name from Makefile. > > Joe, there will delete all this pr_fmt definition in .c file in 3.8(or > 3.7) as you metioned, so we can ingnore this patch. Not quite. The uses that have embedded prefixes need updating. You've done that in bits of this patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, Jul 17, 2012 at 1:07 PM, Joe Perches wrote: > On Tue, 2012-07-17 at 00:25 -0400, Steven Rostedt wrote: >> On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: >> >> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c >> > [] >> > > @@ -13,6 +13,8 @@ >> > > * Copyright (C) 2004 William Lee Irwin III >> > > */ >> > > >> > > +#define pr_fmt(fmt) "ftrace: " fmt >> > >> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> >> Wouldn't a nicer patch be to move this into a header file and then >> remove all the defines throughout the kernel tree? > > Maybe. There are modules that use common header files > like you suggest. It does mean that header must be the > #included before any other #include that might > #include or printk.h. > > Right now, if pr_fmt isn't #defined, printk.h > has a default definition of: > > #ifndef pr_fmt > #define pr_fmt(fmt) fmt > #endif > > My goal is to change that to: > > #ifndef pr_fmt > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > #endif > > in 3.8 (maybe 3.7) and remove all of these then > useless, duplicate #defines shortly afterward. > > https://lkml.org/lkml/2012/3/27/247 > >> Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is >> not a module. > > It depends on the Makefile. > > scripts/Makefile.lib:# $(modname_flags) #defines KBUILD_MODNAME as the name > of the module it will > scripts/Makefile.lib-# end up in (or would, if it gets compiled in) > scripts/Makefile.lib-# Note: Files that end up in two or more modules are > compiled without the > scripts/Makefile.lib:# KBUILD_MODNAME definition. The reason is that > any made-up name would > scripts/Makefile.lib-# differ in different configs. > scripts/Makefile.lib-name-fix = $(subst $(comma),_,$(subst -,_,$1)) > scripts/Makefile.lib-basename_flags = -D"KBUILD_BASENAME=KBUILD_STR($(call > name-fix,$(basetarget)))" > scripts/Makefile.lib-modname_flags = $(if $(filter 1,$(words $(modname))),\ > scripts/Makefile.lib: -D"KBUILD_MODNAME=KBUILD_STR($(call > name-fix,$(modname)))") > Hmm, that would make sense, get subsystem name from Makefile. Joe, there will delete all this pr_fmt definition in .c file in 3.8(or 3.7) as you metioned, so we can ingnore this patch. .Jovi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] staging/gdm72xx: use kthread APIs
From: Devendra Naga
This patch modifies the kthread usage in the gdm_usb code, and tries to
use the kthread APIs better.
Actually the task_struct is taken as global as the limitation of priv.
we run the kthread before we allocate the priv.
did only compilation test, but not the insmod, check ps ax for kthread and
rmmod and see the thread is killed kind of tests.
There were no checks while kthread_run may fail, returing some error which can
be seen by using PTR_ERR.
Signed-off-by: Devendra Naga
---
Sorry Greg sir, i didn't actually used the checkpatch tool, mea maxima clupa :(.
changes since V2:
removed the following checkpatch error
./scripts/checkpatch.pl 0001-staging-gdm72xx-use-kthread-APIs.patch
ERROR: trailing whitespace
#38: FILE: drivers/staging/gdm72xx/gdm_usb.c:57:
+static struct task_struct *kthread; $
NOTE: whitespace errors detected, you may wish to use
scripts/cleanpatch or
scripts/cleanfile
but didn't solved the below warning, as it needed a new patch
to remove all
printk's and convert them to pr_err, and this patch intended to
do only one
specific change.
WARNING: Prefer pr_err(... to printk(KERN_ERR, ...
#58: FILE: drivers/staging/gdm72xx/gdm_usb.c:786:
+ printk(KERN_ERR "%s: can't create kernel thread\n",
__func__);
drivers/staging/gdm72xx/gdm_usb.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/gdm72xx/gdm_usb.c
b/drivers/staging/gdm72xx/gdm_usb.c
index d48d49c..5aab7eb 100644
--- a/drivers/staging/gdm72xx/gdm_usb.c
+++ b/drivers/staging/gdm72xx/gdm_usb.c
@@ -46,7 +46,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
static DECLARE_WAIT_QUEUE_HEAD(k_wait);
static LIST_HEAD(k_list);
static DEFINE_SPINLOCK(k_lock);
-static int k_mode_stop;
#define K_WAIT_TIME(2 * HZ / 100)
@@ -55,6 +54,7 @@ static int k_mode_stop;
static int init_usb(struct usbwm_dev *udev);
static void release_usb(struct usbwm_dev *udev);
+static struct task_struct *kthread;
/*#define DEBUG */
#ifdef DEBUG
static void hexdump(char *title, u8 *data, int len)
@@ -717,7 +717,7 @@ static int k_mode_thread(void *arg)
daemonize("k_mode_wimax");
- while (!k_mode_stop) {
+ while (!kthread_should_stop()) {
spin_lock_irqsave(&k_lock, flags2);
while (!list_empty(&k_list)) {
@@ -778,7 +778,11 @@ static struct usb_driver gdm_usb_driver = {
static int __init usb_gdm_wimax_init(void)
{
#ifdef CONFIG_WIMAX_GDM72XX_K_MODE
- kthread_run(k_mode_thread, NULL, "WiMax_thread");
+ kthread = kthread_run(k_mode_thread, NULL, "WiMax_thread");
+ if (IS_ERR(kthread)) {
+ printk(KERN_ERR "%s: can't create kernel thread\n", __func__);
+ return PTR_ERR(kthread);
+ }
#endif /* CONFIG_WIMAX_GDM72XX_K_MODE */
return usb_register(&gdm_usb_driver);
}
@@ -786,7 +790,8 @@ static int __init usb_gdm_wimax_init(void)
static void __exit usb_gdm_wimax_exit(void)
{
#ifdef CONFIG_WIMAX_GDM72XX_K_MODE
- k_mode_stop = 1;
+ if (kthread)
+ kthread_stop(kthread);
wake_up(&k_wait);
#endif
usb_deregister(&gdm_usb_driver);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 13:23 +0800, Jovi Zhang wrote: > I don't make sure if there have some method or skill to let GCC knows > subsystem name automatically, > use built-in macro __FILE__? but this need condition of subsystem name > is same as file name, > not so easily to guarantee that. You could use KBUILD_BASENAME instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 13:23 +0800, Jovi Zhang wrote: > On Tue, Jul 17, 2012 at 12:25 PM, Steven Rostedt wrote: > > On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > > > >> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > >> [] > >> > @@ -13,6 +13,8 @@ > >> > * Copyright (C) 2004 William Lee Irwin III > >> > */ > >> > > >> > +#define pr_fmt(fmt) "ftrace: " fmt > >> > >> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > > > Wouldn't a nicer patch be to move this into a header file and then > > remove all the defines throughout the kernel tree? > > Maybe it's hard to achieve that. > subsystem name is unique with each other, it should be visible in source file, > if include into header file, then each .c file might need a own header > file for include pr_fmt > definition, then that header file cannot be reusable(avoid subsystem > name conflicts). > > > > > Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > > not a module. > Yes, that's why I cannot use KBUILD_MODNAME in patch. Incorrect, try it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Adding support for configuring polarity in PWM framework.
On Mon, Jul 16, 2012 at 18:16:13, Lars-Peter Clausen wrote: > On 07/16/2012 02:23 PM, Philip, Avinash wrote: > > > > > 1. PWM framework API addition. > > PWM frame work API support. > > /** > > * pwm_setpolarity() - change a PWM device Polarity > > * @pwm: PWM device > > * @polarity: Configure polarity of PWM > > * > > * polarity - false -> "on" time defined by duty ns > > * - true -> "off' time defined by duty ns. > > */ > > Isn't this more about whether we start with a low or a high signal? No, it is more about the average on time. On time determines the on duration of the panel power and there by brightness. On one custom board, backlight power booster gives power output on the OFF time of PWM (hardware connection). > If it is > just about the duty time you can easily achieve the same effect by setting > it to (period_ns - duty_ns). Yes this is possible. But the PWM hardware we uses supports configuration of polarity. So I prefer PWM polarity configuration. Also with polarity configuration support, we can achieve (period_ns - duty_ns), for PWM devices don't have hardware support. Polarity configuration support can be used for setting flags, duty cycle can be configured from config depending on flag. Thanks Avinash > > - Lars > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net-next: make sock diag per-namespace (v2)
From: Andrew Vagin Date: Mon, 16 Jul 2012 18:28:49 +0400 > Before this patch sock_diag works for init_net only and dumps > information about sockets from all namespaces. > > This patch expands sock_diag for all name-spaces. > It creates a netlink kernel socket for each netns and filters > data during dumping. > > v2: filter accoding with netns in all places > remove an unused variable. > > Signed-off-by: Andrew Vagin Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, Jul 17, 2012 at 12:25 PM, Steven Rostedt wrote: > On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > >> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c >> [] >> > @@ -13,6 +13,8 @@ >> > * Copyright (C) 2004 William Lee Irwin III >> > */ >> > >> > +#define pr_fmt(fmt) "ftrace: " fmt >> >> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > Wouldn't a nicer patch be to move this into a header file and then > remove all the defines throughout the kernel tree? Maybe it's hard to achieve that. subsystem name is unique with each other, it should be visible in source file, if include into header file, then each .c file might need a own header file for include pr_fmt definition, then that header file cannot be reusable(avoid subsystem name conflicts). > > Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > not a module. Yes, that's why I cannot use KBUILD_MODNAME in patch. > > -- Steve I don't make sure if there have some method or skill to let GCC knows subsystem name automatically, use built-in macro __FILE__? but this need condition of subsystem name is same as file name, not so easily to guarantee that. .jovi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [RFC] cpufreq: omap: scale regulator from clk notifier
On Saturday 14 July 2012 05:46 AM, Mike Turquette wrote:
This patch moves direct control of the MPU voltage regulator out of the
cpufreq driver .target callback and instead puts that logic into a clock
rate change notifier callback.
The same frequency/voltage lookup via the OPP library is present, except
that the calls to regulator_set_voltage are done from the clock
framework instead of cpufreq.
Ideally it would be nice to reduce the .target callback for OMAP's
cpufreq driver to a simple call to clk_set_rate. For now there is still
some other stuff needed there (jiffies per loop, rounding the rate, etc
etc).
Not-signed-off-by: Mike Turquette
---
drivers/cpufreq/omap-cpufreq.c | 154 +---
1 file changed, 96 insertions(+), 58 deletions(-)
-static int __init omap_cpufreq_init(void)
+static int mpu_clk_volt_scale_handler(struct notifier_block *nb,
+ unsigned long flags, void *data)
{
- 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";
+ struct clk_notifier_data *cnd = data;
+ unsigned long tol;
+ int ret, volt_new, volt_old;
+ struct opp *opp;
- if (!mpu_clk_name) {
- pr_err("%s: unsupported Silicon?\n", __func__);
- return -EINVAL;
+ volt_old = regulator_get_voltage(mpu_reg);
+ opp = opp_find_freq_exact(mpu_dev, cnd->new_rate, true);
+ volt_new = opp_get_voltage(opp);
+
+ tol = volt_new * OPP_TOLERANCE / 100;
+
+ /* scaling up? scale voltage before frequency */
+ if (cnd->new_rate> cnd->old_rate) {
+ dev_dbg(mpu_dev, "cpufreq-omap: %d mV --> %d mV\n",
+ volt_old, volt_new);
+
+ ret = regulator_set_voltage(mpu_reg, volt_new - tol, volt_new +
tol);
+
+ if (ret< 0) {
+ dev_warn(mpu_dev, "%s: unable to scale voltage up.\n",
+__func__);
+ return NOTIFY_BAD;
+ }
+ }
+
+ /* scaling down? scale voltage after frequency */
+ if (cnd->new_rate< cnd->old_rate) {
+ dev_dbg(mpu_dev, "cpufreq-omap: %d mV --> %d mV\n",
+ volt_old, volt_new);
+
+ ret = regulator_set_voltage(mpu_reg, volt_new - tol, volt_new +
tol);
+
+ if (ret< 0) {
+ dev_warn(mpu_dev, "%s: unable to scale voltage down.\n",
+__func__);
+ return NOTIFY_BAD;
+ }
}
How are you checking pre and post rate change condition here? Need
switch case for event?
+ return NOTIFY_OK;
+}
+
+static struct notifier_block mpu_clk_volt_scale_nb = {
+ .notifier_call = mpu_clk_volt_scale_handler,
+};
+
+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/17 14:17, Wen Congyang wrote:
> At 07/17/2012 12:51 PM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 12:32, Wen Congyang wrote:
>>> At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/17 11:32, Wen Congyang wrote:
> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
>>> Hi Wen,
>>>
>>> 2012/07/13 12:35, Wen Congyang wrote:
At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical
> memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
>- offline memory
>- remove physical memory (only return -EBUSY)
>- free acpi_memory_device
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/acpi/acpi_memhotplug.c | 26 +-
> drivers/base/memory.c | 39
> +++
> include/linux/memory.h |5 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c|8
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
> ===
> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:29.946888653 +0900
> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:43.470719531 +0900
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
> static int acpi_memory_device_remove(struct acpi_device
> *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + struct acpi_memory_info *info, *tmp;
> + int result;
> + int node;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + node = acpi_get_node(mem_device->device->handle);
> +
> + list_for_each_entry_safe(info, tmp, &mem_device->res_list,
> list) {
> + if (!info->enabled)
> + continue;
> +
> + if (!is_memblk_offline(info->start_addr, info->length))
> {
> + result = offline_memory(info->start_addr,
> info->length);
> + if (result)
> + return result;
> + }
> +
> + result = remove_memory(node, info->start_addr,
> info->length);
The user may online the memory between offline_memory() and
remove_memory().
So I think we should lock memory hotplug before check the memory's
status
and release it after remove_memory().
>>>
>>> How about get "mem_block->state_mutex" of removed memory? When offlining
>>> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
>>> In this case, we get mem_block->state_mutex. So I think the mutex lock
>>> is beneficial.
>>
>> It is not good idea since remove_memory frees mem_block structure...
>> Do you have any ideas?
>
> Hmm, split offline_memory() to 2 functions: offline_pages() and
> __offline_pages()
>
> offline_pages()
> lock_memory_hotplug();
> __offline_pages();
> unlock_memory_hotplug();
>
> and implement remove_memory() like this:
> remove_memory()
> lock_memory_hotplug()
> if (!is_memblk_offline()) {
> __offline_pages();
> }
> // cleanup
> unlock_memory_hotplug();
>
> What about this?
I also thought about it once. But a problem remains. Current
offilne_pages()
cannot realize the memory has been removed by remove_memory(). So even if
protecting the race by lock_memory_hotplug(), offline_pages() can offline
the removed memory. offline_pages() should have
Re: [PATCH 2/2] x86: reimplement mem boot option
At 06/28/2012 09:29 AM, Wen Congyang Wrote:
> Pin..
Ping again
>
> At 06/14/2012 04:12 PM, Wen Congyang Wrote:
>> Current mem boot option only can work for non efi environment. If the user
>> specifies add_efi_memmap, it cannot work for efi environment. In
>> the efi environment, we call e820_add_region() to add the memory map. So
>> we can modify __e820_add_region() and the mem boot option can work for
>> efi environment.
>>
>> Signed-off-by: Wen Congyang
>> ---
>> arch/x86/kernel/e820.c | 29 +
>> 1 files changed, 25 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
>> index 4185797..20bc467 100644
>> --- a/arch/x86/kernel/e820.c
>> +++ b/arch/x86/kernel/e820.c
>> @@ -47,6 +47,7 @@ unsigned long pci_mem_start = 0xaeedbabe;
>> #ifdef CONFIG_PCI
>> EXPORT_SYMBOL(pci_mem_start);
>> #endif
>> +static u64 mem_limit = ~0ULL;
>>
>> /*
>> * This function checks if any part of the range is mapped
>> @@ -119,6 +120,20 @@ static void __init __e820_add_region(struct e820map
>> *e820x, u64 start, u64 size,
>> return;
>> }
>>
>> +if (start >= mem_limit) {
>> +printk(KERN_ERR "e820: ignoring [mem %#010llx-%#010llx]\n",
>> + (unsigned long long)start,
>> + (unsigned long long)(start + size - 1));
>> +return;
>> +}
>> +
>> +if (mem_limit - start < size) {
>> +printk(KERN_ERR "e820: ingoring [mem %#010llx-%#010llx]\n",
>> + (unsigned long long)mem_limit,
>> + (unsigned long long)(start + size - 1));
>> +size = mem_limit - start;
>> +}
>> +
>> e820x->map[x].addr = start;
>> e820x->map[x].size = size;
>> e820x->map[x].type = type;
>> @@ -809,7 +824,7 @@ static int userdef __initdata;
>> /* "mem=nopentium" disables the 4MB page tables. */
>> static int __init parse_memopt(char *p)
>> {
>> -u64 mem_size;
>> +char *oldp;
>>
>> if (!p)
>> return -EINVAL;
>> @@ -825,11 +840,11 @@ static int __init parse_memopt(char *p)
>> }
>>
>> userdef = 1;
>> -mem_size = memparse(p, &p);
>> +oldp = p;
>> +mem_limit = memparse(p, &p);
>> /* don't remove all of memory when handling "mem={invalid}" param */
>> -if (mem_size == 0)
>> +if (mem_limit == 0 || p == oldp)
>> return -EINVAL;
>> -e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1);
>>
>> return 0;
>> }
>> @@ -881,6 +896,12 @@ early_param("memmap", parse_memmap_opt);
>>
>> void __init finish_e820_parsing(void)
>> {
>> +if (mem_limit != ~0ULL) {
>> +userdef = 1;
>> +e820_remove_range(mem_limit, ULLONG_MAX - mem_limit,
>> + E820_RAM, 1);
>> +}
>> +
>> if (userdef) {
>> u32 nr = e820.nr_map;
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready
On Tue, Jul 17, 2012 at 12:04 AM, Arve Hjønnevåg wrote: > On Mon, Jul 16, 2012 at 4:00 AM, Rafael J. Wysocki wrote: >> On Monday, July 16, 2012, Michael Kerrisk wrote: >>> Arve, Rafael, >>> >>> On Tue, May 1, 2012 at 7:33 AM, Arve Hjønnevåg wrote: >>> > When an epoll_event, that has the EPOLLWAKEUP flag set, is ready, a >>> > wakeup_source will be active to prevent suspend. This can be used to >>> > handle wakeup events from a driver that support poll, e.g. input, if >>> > that driver wakes up the waitqueue passed to epoll before allowing >>> > suspend. >>> >>> It's late it the -rc series, >> >> Well, exactly. :-) If someone had CCed linux-api@ along the way (as per Documentation/SubmitChecklist), it might have helped ;-) >> >>> but it strikes me that CAP_EPOLLWAKEUP is >>> a poor name for the capability that governs the use of EPOLLWAKEUP. >>> While on the one hand some capabilities are overloaded >>> (https://lwn.net/Articles/486306/), on the other hand we should avoid >>> adding individual capabilities for each new API feature (otherwise >>> capabilities become administratively unwieldy). >>> >>> This capability is not really about "EPOLL". It's about the ability to >>> block system suspend. Therefore, IMO, a better name would be something >>> like: CAP_BLOCK_SUSPEND. This name is better because there might be >>> some other API feature that is later added that also has the effect of >>> preventing system suspends, and we could reasonably govern that >>> feature with the same capability. > > We already have another api, "/sys/power/wake_lock", that allow > user-space to block suspend. Do we want to apply this capability that > api as well, or only to apis that do not have other ways to restrict > access? Well, the question is: is there a governor on the use of /sys/power/wake_lock? It makes sense either they are both governed (preferably by the same mechanism, I would have thought), or neither is. >>> Does that seem sensible to you? I can send a patch for the name change. >> >> I'm not sure what Arve thinks about that, but I'd be fine with that. >> >> Arve, what do you think? >> > > CAP_BLOCK_SUSPEND is fine with me, but if it does not apply to the > sysfs interface, then the comment should probably mention this. I've sent a patch, but omitted mention of API details in the comments. Maybe that can be changed afterward, when a decision has been reached about governing /sys/power/wake_lock. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers: bus: add a new driver for omap-ocp2scp
+Arnd Bergmann
On Mon, Jul 16, 2012 at 7:43 PM, Kishon Vijay Abraham I wrote:
> Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
> creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
> USB2PHY is connected to ocp2scp.
>
> This also includes device tree support for ocp2scp driver and
> the documentation with device tree binding information is updated.
>
> Cc: Felipe Balbi
> Cc: Arnd Bergmann
> Signed-off-by: Kishon Vijay Abraham I
> ---
> .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 ++
> drivers/Kconfig|2 +
> drivers/Makefile |2 +
> drivers/bus/Kconfig| 15 +++
> drivers/bus/Makefile |5 +
> drivers/bus/omap-ocp2scp.c | 98
>
> 6 files changed, 132 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> create mode 100644 drivers/bus/Kconfig
> create mode 100644 drivers/bus/Makefile
> create mode 100644 drivers/bus/omap-ocp2scp.c
>
> diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> new file mode 100644
> index 000..d2fe064
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> @@ -0,0 +1,10 @@
> +* OMAP OCP2SCP - ocp interface to scp interface
> +
> +properties:
> +- compatible : Should be "ti,omap-ocp2scp"
> +- #address-cells, #size-cells : Must be present if the device has sub-nodes
> +- ranges : the child address space are mapped 1:1 onto the parent address
> space
> +- ti,hwmods : must be "ocp2scp_usb_phy"
> +
> +Sub-nodes:
> +All the devices connected to ocp2scp are described using sub-node to ocp2scp
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index bfc9186..4fe1e4c 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -2,6 +2,8 @@ menu "Device Drivers"
>
> source "drivers/base/Kconfig"
>
> +source "drivers/bus/Kconfig"
> +
> source "drivers/connector/Kconfig"
>
> source "drivers/mtd/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 2ba29ff..cac3819 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -5,6 +5,8 @@
> # Rewritten to use lists instead of if-statements.
> #
>
> +obj-y += bus/
> +
> # GPIO must come after pinctrl as gpios may need to mux pins etc
> obj-y += pinctrl/
> obj-y += gpio/
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> new file mode 100644
> index 000..6270415
> --- /dev/null
> +++ b/drivers/bus/Kconfig
> @@ -0,0 +1,15 @@
> +#
> +# Bus Devices
> +#
> +
> +menu "Bus devices"
> +
> +config OMAP_OCP2SCP
> + tristate "OMAP OCP2SCP DRIVER"
> + help
> + Driver to enable ocp2scp module which transforms ocp interface
> + protocol to scp protocol. In OMAP4, USB PHY is connected via
> + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
> + OCP2SCP.
> +
> +endmenu
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> new file mode 100644
> index 000..0ec50bc
> --- /dev/null
> +++ b/drivers/bus/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the bus drivers.
> +#
> +
> +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
> diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
> new file mode 100644
> index 000..8c3db3a
> --- /dev/null
> +++ b/drivers/bus/omap-ocp2scp.c
> @@ -0,0 +1,98 @@
> +/*
> + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Author: Kishon Vijay Abraham I
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int ocp2scp_remove_devices(struct device *dev, void *c)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> +
> + platform_device_unregister(pdev);
> +
> + return 0;
> +}
> +
> +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
> +{
> + int ret;
> + struct device_node *np = pdev->dev.of_node;
> +
> + if (np) {
> + ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
> + if (ret) {
> + dev_
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/17/2012 12:51 PM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/07/17 12:32, Wen Congyang wrote:
>> At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
>>> Hi Wen,
>>>
>>> 2012/07/17 11:32, Wen Congyang wrote:
At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
>> Hi Wen,
>>
>> 2012/07/13 12:35, Wen Congyang wrote:
>>> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
acpi_memory_device_remove() has been prepared to remove physical
memory.
But, the function only frees acpi_memory_device currentlry.
The patch adds following functions into acpi_memory_device_remove():
- offline memory
- remove physical memory (only return -EBUSY)
- free acpi_memory_device
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/acpi_memhotplug.c | 26 +-
drivers/base/memory.c | 39
+++
include/linux/memory.h |5 +
include/linux/memory_hotplug.h |1 +
mm/memory_hotplug.c|8
5 files changed, 78 insertions(+), 1 deletion(-)
Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
===
--- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
18:08:29.946888653 +0900
+++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
18:08:43.470719531 +0900
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
static int acpi_memory_device_remove(struct acpi_device *device,
int type)
{
struct acpi_memory_device *mem_device = NULL;
-
+ struct acpi_memory_info *info, *tmp;
+ int result;
+ int node;
if (!device || !acpi_driver_data(device))
return -EINVAL;
mem_device = acpi_driver_data(device);
+
+ node = acpi_get_node(mem_device->device->handle);
+
+ list_for_each_entry_safe(info, tmp, &mem_device->res_list,
list) {
+ if (!info->enabled)
+ continue;
+
+ if (!is_memblk_offline(info->start_addr, info->length))
{
+ result = offline_memory(info->start_addr,
info->length);
+ if (result)
+ return result;
+ }
+
+ result = remove_memory(node, info->start_addr,
info->length);
>>>
>>> The user may online the memory between offline_memory() and
>>> remove_memory().
>>> So I think we should lock memory hotplug before check the memory's
>>> status
>>> and release it after remove_memory().
>>
>> How about get "mem_block->state_mutex" of removed memory? When offlining
>> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
>> In this case, we get mem_block->state_mutex. So I think the mutex lock
>> is beneficial.
>
> It is not good idea since remove_memory frees mem_block structure...
> Do you have any ideas?
Hmm, split offline_memory() to 2 functions: offline_pages() and
__offline_pages()
offline_pages()
lock_memory_hotplug();
__offline_pages();
unlock_memory_hotplug();
and implement remove_memory() like this:
remove_memory()
lock_memory_hotplug()
if (!is_memblk_offline()) {
__offline_pages();
}
// cleanup
unlock_memory_hotplug();
What about this?
>>>
>>> I also thought about it once. But a problem remains. Current offilne_pages()
>>> cannot realize the memory has been removed by remove_memory(). So even if
>>> protecting the race by lock_memory_hotplug(), offline_pages() can offline
>>> the removed memory. offline_pages() should have the means to know the memory
>>> was removed. But I don't have good idea.
>>
>> We can not online/offline part of memory block, so what about this?
>
> It seems you do not understand my concern.
> When
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 00:25 -0400, Steven Rostedt wrote: > On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > > > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > > [] > > > @@ -13,6 +13,8 @@ > > > * Copyright (C) 2004 William Lee Irwin III > > > */ > > > > > > +#define pr_fmt(fmt) "ftrace: " fmt > > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > Wouldn't a nicer patch be to move this into a header file and then > remove all the defines throughout the kernel tree? Maybe. There are modules that use common header files like you suggest. It does mean that header must be the #included before any other #include that might #include or printk.h. Right now, if pr_fmt isn't #defined, printk.h has a default definition of: #ifndef pr_fmt #define pr_fmt(fmt) fmt #endif My goal is to change that to: #ifndef pr_fmt #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #endif in 3.8 (maybe 3.7) and remove all of these then useless, duplicate #defines shortly afterward. https://lkml.org/lkml/2012/3/27/247 > Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > not a module. It depends on the Makefile. scripts/Makefile.lib:# $(modname_flags) #defines KBUILD_MODNAME as the name of the module it will scripts/Makefile.lib-# end up in (or would, if it gets compiled in) scripts/Makefile.lib-# Note: Files that end up in two or more modules are compiled without the scripts/Makefile.lib:# KBUILD_MODNAME definition. The reason is that any made-up name would scripts/Makefile.lib-# differ in different configs. scripts/Makefile.lib-name-fix = $(subst $(comma),_,$(subst -,_,$1)) scripts/Makefile.lib-basename_flags = -D"KBUILD_BASENAME=KBUILD_STR($(call name-fix,$(basetarget)))" scripts/Makefile.lib-modname_flags = $(if $(filter 1,$(words $(modname))),\ scripts/Makefile.lib: -D"KBUILD_MODNAME=KBUILD_STR($(call name-fix,$(modname)))") -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 on 3.5-rc6
Hi Dave, On Tue, Jul 17, 2012 at 12:16 AM, Dave Jones wrote: > > Check the bugs-found.txt file in trinity.git before reporting bugs found with > it. > This one already got reported.. https://lkml.org/lkml/2012/7/13/328 > I try to keep that file up to date to reduce multiple reports of the same bug. > (also, for that reason, please cc me on bugs you find with it!) > > thanks, > > Dave Thanks, Sorry for not seeing the bug-list. I will cc you in every bug reported from trinity. Devendra -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] kvm tools, powerpc: Use mmap_anon_or_hugetblfs() in kvm__arch_init()
It implements essentially the same logic. The one difference is it sets
MAP_NORESERVE when using anonymous mmap, but I think that is OK.
Reword the comment about hugetblfs, we are no longer required to use
hugepages to back the guest.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/kvm.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index cbc0d8f..0d8a9da 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -97,20 +97,12 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
kvm->ram_size = ram_size;
- /*
-* Currently, HV-mode PPC64 SPAPR requires that we map from hugetlfs.
-* Allow a 'default' option to assist.
-* PR-mode does not require this.
-*/
- if (hugetlbfs_path) {
- if (!strcmp(hugetlbfs_path, "default"))
- hugetlbfs_path = HUGETLBFS_PATH;
- kvm->ram_start = mmap_hugetlbfs(hugetlbfs_path, kvm->ram_size);
- } else {
- kvm->ram_start = mmap(0, kvm->ram_size, PROT_READ | PROT_WRITE,
- MAP_ANON | MAP_PRIVATE,
- -1, 0);
- }
+ /* Map "default" hugetblfs path to the standard 16M mount point */
+ if (hugetlbfs_path && !strcmp(hugetlbfs_path, "default"))
+ hugetlbfs_path = HUGETLBFS_PATH;
+
+ kvm->ram_start = mmap_anon_or_hugetlbfs(hugetlbfs_path, kvm->ram_size);
+
if (kvm->ram_start == MAP_FAILED)
die("Couldn't map %lld bytes for RAM (%d)\n",
kvm->ram_size, errno);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] kvm tools, powerpc: Use designated initializers for struct cpu_info
Using designated initializers for structs is preferable because it
is self documenting, and more robust against changes to the structure
layout.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c | 38 +-
tools/kvm/powerpc/cpu_info.h |6 +++---
2 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index c364b74..ad27451 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -30,14 +30,16 @@ static u32 power7_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc,
0x0, 0x18, 0x100, 0x1
static u32 power7_segment_sizes_prop[] = {0x1c, 0x28, 0x, 0x};
static struct cpu_info cpu_power7_info = {
- "POWER7",
- power7_page_sizes_prop, sizeof(power7_page_sizes_prop),
- power7_segment_sizes_prop, sizeof(power7_segment_sizes_prop),
- 32, /* SLB size */
- 51200, /* TB frequency */
- 128,/* d-cache block size */
- 128,/* i-cache block size */
- CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX
+ .name = "POWER7",
+ .page_sizes_prop = power7_page_sizes_prop,
+ .page_sizes_prop_len = sizeof(power7_segment_sizes_prop),
+ .segment_sizes_prop = power7_segment_sizes_prop,
+ .segment_sizes_prop_len = sizeof(power7_segment_sizes_prop),
+ .slb_size = 32,
+ .tb_freq = 51200,
+ .d_bsize = 128,
+ .i_bsize = 128,
+ .flags = CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX,
};
/* PPC970/G5 */
@@ -45,18 +47,20 @@ static struct cpu_info cpu_power7_info = {
static u32 g5_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc, 0x0, 0x18, 0x100, 0x1,
0x18, 0x0};
static struct cpu_info cpu_970_info = {
- "G5",
- g5_page_sizes_prop, sizeof(g5_page_sizes_prop),
- 0 /* Null = no segment sizes prop, use defaults */, 0,
- 0, /* SLB size default */
- , /* TB frequency */
- 128,/* d-cache block size */
- 128,/* i-cache block size */
- CPUINFO_FLAG_VMX
+ .name = "G5",
+ .page_sizes_prop = g5_page_sizes_prop,
+ .page_sizes_prop_len = sizeof(g5_page_sizes_prop),
+ .segment_sizes_prop = NULL /* no segment sizes prop, use defaults */,
+ .segment_sizes_prop_len = 0,
+ .slb_size = 0,
+ .tb_freq = ,
+ .d_bsize = 128,
+ .i_bsize = 128,
+ .flags = CPUINFO_FLAG_VMX,
};
/* This is a default catchall for 'no match' on PVR: */
-static struct cpu_info cpu_dummy_info = { "unknown", 0, 0, 0, 0, 0, 0, 0, 0 };
+static struct cpu_info cpu_dummy_info = { .name = "unknown" };
static struct pvr_info host_pvr_info[] = {
{ 0x, 0x0f03, &cpu_power7_info },
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 4a43ed5..2115c7f 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -21,9 +21,9 @@ struct cpu_info {
u32 *segment_sizes_prop;
u32 segment_sizes_prop_len;
u32 slb_size;
- u32 tb_freq;
- u32 d_bsize;
- u32 i_bsize;
+ u32 tb_freq; /* timebase frequency */
+ u32 d_bsize; /* d-cache block size */
+ u32 i_bsize; /* i-cache block size */
u32 flags;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] kvm tools, powerpc: Reformatting in find_cpu_info()
Matt's enter key was broken when he wrote this ;)
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 7326f5b..586b232 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -75,13 +75,15 @@ static struct pvr_info host_pvr_info[] = {
struct cpu_info *find_cpu_info(u32 pvr)
{
unsigned int i;
+
for (i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
- if ((pvr & host_pvr_info[i].pvr_mask) ==
- host_pvr_info[i].pvr) {
+ if ((pvr & host_pvr_info[i].pvr_mask) == host_pvr_info[i].pvr) {
return host_pvr_info[i].cpu_info;
}
}
+
/* Didn't find anything? Rut-ro. */
pr_warning("Host CPU unsupported by kvmtool\n");
+
return &cpu_dummy_info;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/10] kvm tools, powerpc: Restructure find_cpu_info()
We are about to add more logic to find_cpu_info(). To support this we
need to pass kvm through to it, and also restructure the return flow
so we can operate on info before it is returned.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c | 16 +++-
tools/kvm/powerpc/cpu_info.h |4 +++-
tools/kvm/powerpc/kvm.c |2 +-
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 586b232..5015a4b 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -72,18 +72,24 @@ static struct pvr_info host_pvr_info[] = {
{ 0x, 0x0045, &cpu_970_info },
};
-struct cpu_info *find_cpu_info(u32 pvr)
+struct cpu_info *find_cpu_info(struct kvm *kvm)
{
+ struct cpu_info *info;
unsigned int i;
+ u32 pvr = kvm->pvr;
- for (i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
+ for (info = NULL, i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
if ((pvr & host_pvr_info[i].pvr_mask) == host_pvr_info[i].pvr) {
- return host_pvr_info[i].cpu_info;
+ info = host_pvr_info[i].cpu_info;
+ break;
}
}
/* Didn't find anything? Rut-ro. */
- pr_warning("Host CPU unsupported by kvmtool\n");
+ if (!info) {
+ pr_warning("Host CPU unsupported by kvmtool\n");
+ info = &cpu_dummy_info;
+ }
- return &cpu_dummy_info;
+ return info;
}
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 2115c7f..439f3940 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -11,6 +11,8 @@
#ifndef CPU_INFO_H
#define CPU_INFO_H
+#include
+
#include
#include
@@ -38,6 +40,6 @@ struct pvr_info {
#define CPUINFO_FLAG_VMX 0x0002
#define CPUINFO_FLAG_VSX 0x0004
-struct cpu_info *find_cpu_info(u32 pvr);
+struct cpu_info *find_cpu_info(struct kvm *kvm);
#endif
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index e3a7e52..dbfea3e 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -229,7 +229,7 @@ static void setup_fdt(struct kvm *kvm)
int i, j;
charcpu_name[30];
u8 staging_fdt[FDT_MAX_SIZE];
- struct cpu_info *cpu_info = find_cpu_info(kvm->pvr);
+ struct cpu_info *cpu_info = find_cpu_info(kvm);
/* Generate an appropriate DT at kvm->fdt_gra */
void *fdt_dest = guest_flat_to_host(kvm, kvm->fdt_gra);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] Use kernel supplied MMU info for kvm tool
Hi all, This is a series for kvmtool that uses a newish kernel API to get MMU info, which is then fed to the guest. Currently we just make a good guess based on the PVR, but that is potentially flakey in a few ways. The most notable is that if you don't specify hugepages we don't boot - because the guest is told we support 16M pages, but we don't really (on HV). I've tested this with 4K/64K host page size, and with hugepages, on both 3.4 and 3.5 based host kernels. I've also given it a quick smoke test with PR KVM, and it seems to work. I'm seeing a guest crash with a 4K host kernel, but I think that is unrelated, and happens with or without this patch series. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/10] kvm tools, powerpc: Use MMU info for ibm,slb-size
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |3 +--
tools/kvm/powerpc/cpu_info.h |1 -
tools/kvm/powerpc/kvm.c |5 +++--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 82a9d4f..1f440a5 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -25,13 +25,13 @@
static struct cpu_info cpu_power7_info = {
.name = "POWER7",
- .slb_size = 32,
.tb_freq = 51200,
.d_bsize = 128,
.i_bsize = 128,
.flags = CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX,
.mmu_info = {
.flags = KVM_PPC_PAGE_SIZES_REAL | KVM_PPC_1T_SEGMENTS,
+ .slb_size = 32,
},
};
@@ -39,7 +39,6 @@ static struct cpu_info cpu_power7_info = {
static struct cpu_info cpu_970_info = {
.name = "G5",
- .slb_size = 0,
.tb_freq = ,
.d_bsize = 128,
.i_bsize = 128,
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 00b9436b..f61707a 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -19,7 +19,6 @@
struct cpu_info {
const char *name;
- u32 slb_size;
u32 tb_freq; /* timebase frequency */
u32 d_bsize; /* d-cache block size */
u32 i_bsize; /* i-cache block size */
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index 8353355..83b8edd 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -393,8 +393,9 @@ static void setup_fdt(struct kvm *kvm)
/* Lies, but safeish lies! */
_FDT(fdt_property_cell(fdt, "clock-frequency", 0xddbab200));
- if (cpu_info->slb_size)
- _FDT(fdt_property_cell(fdt, "ibm,slb-size",
cpu_info->slb_size));
+ if (cpu_info->mmu_info.slb_size)
+ _FDT(fdt_property_cell(fdt, "ibm,slb-size",
cpu_info->mmu_info.slb_size));
+
/*
* HPT size is hardwired; KVM currently fixes it at 16MB but the
* moment that changes we'll need to read it out of the kernel.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] kvm tools, powerpc: Use MMU info for ibm,processor-segment-sizes
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |7 ---
tools/kvm/powerpc/cpu_info.h |2 --
tools/kvm/powerpc/kvm.c |7 ---
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 1cfb50d..82a9d4f 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -23,13 +23,8 @@
/* POWER7 */
-/* POWER7 has 1T segments, so advertise these */
-static u32 power7_segment_sizes_prop[] = {0x1c, 0x28, 0x, 0x};
-
static struct cpu_info cpu_power7_info = {
.name = "POWER7",
- .segment_sizes_prop = power7_segment_sizes_prop,
- .segment_sizes_prop_len = sizeof(power7_segment_sizes_prop),
.slb_size = 32,
.tb_freq = 51200,
.d_bsize = 128,
@@ -44,8 +39,6 @@ static struct cpu_info cpu_power7_info = {
static struct cpu_info cpu_970_info = {
.name = "G5",
- .segment_sizes_prop = NULL /* no segment sizes prop, use defaults */,
- .segment_sizes_prop_len = 0,
.slb_size = 0,
.tb_freq = ,
.d_bsize = 128,
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 9da6afe..00b9436b 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -19,8 +19,6 @@
struct cpu_info {
const char *name;
- u32 *segment_sizes_prop;
- u32 segment_sizes_prop_len;
u32 slb_size;
u32 tb_freq; /* timebase frequency */
u32 d_bsize; /* d-cache block size */
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index 293812a..8353355 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -299,6 +299,7 @@ static void setup_fdt(struct kvm *kvm)
u8 staging_fdt[FDT_MAX_SIZE];
struct cpu_info *cpu_info = find_cpu_info(kvm);
struct fdt_prop segment_page_sizes;
+ u32 segment_sizes_1T[] = {0x1c, 0x28, 0x, 0x};
/* Generate an appropriate DT at kvm->fdt_gra */
void *fdt_dest = guest_flat_to_host(kvm, kvm->fdt_gra);
@@ -424,10 +425,10 @@ static void setup_fdt(struct kvm *kvm)
segment_page_sizes.value,
segment_page_sizes.size));
- if (cpu_info->segment_sizes_prop)
+ if (cpu_info->mmu_info.flags & KVM_PPC_1T_SEGMENTS)
_FDT(fdt_property(fdt, "ibm,processor-segment-sizes",
- cpu_info->segment_sizes_prop,
- cpu_info->segment_sizes_prop_len));
+ segment_sizes_1T,
sizeof(segment_sizes_1T)));
+
/* VSX / DFP options: */
if (cpu_info->flags & CPUINFO_FLAG_VMX)
_FDT(fdt_property_cell(fdt, "ibm,vmx",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] kvm tools, powerpc: Use MMU info from the kernel for ibm,segment-page-sizes
Recent kernels (>= v3.5-rc1) have an ioctl which allows us to retrieve the
list of page sizes supported for the guest.
So rework the cpu info code to use that ioctl when available, falling
back to the same values we used previously if the ioctl is not present.
We may also need to filter the list of page sizes against the page size
of the memory backing guest RAM - this accounts for the unfortunate amount
of code in setup_mmu_info().
Finally we need to turn the structure as returned by the kernel into the
format expected in the device tree.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c | 132 ++
tools/kvm/powerpc/cpu_info.h |4 +-
tools/kvm/powerpc/kvm.c | 81 +-
3 files changed, 200 insertions(+), 17 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 5015a4b..1cfb50d 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -15,24 +15,19 @@
* by the Free Software Foundation.
*/
+#include
+#include
+
#include "cpu_info.h"
#include "kvm/util.h"
/* POWER7 */
-/*
- * Basic set of pages for POWER7. It actually supports more but there were
some
- * limitations as to which may be advertised to the guest. FIXME when this
- * settles down -- for now use basic set:
- */
-static u32 power7_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc, 0x0, 0x18, 0x100,
0x1, 0x18, 0x0};
/* POWER7 has 1T segments, so advertise these */
static u32 power7_segment_sizes_prop[] = {0x1c, 0x28, 0x, 0x};
static struct cpu_info cpu_power7_info = {
.name = "POWER7",
- .page_sizes_prop = power7_page_sizes_prop,
- .page_sizes_prop_len = sizeof(power7_segment_sizes_prop),
.segment_sizes_prop = power7_segment_sizes_prop,
.segment_sizes_prop_len = sizeof(power7_segment_sizes_prop),
.slb_size = 32,
@@ -40,16 +35,15 @@ static struct cpu_info cpu_power7_info = {
.d_bsize = 128,
.i_bsize = 128,
.flags = CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX,
+ .mmu_info = {
+ .flags = KVM_PPC_PAGE_SIZES_REAL | KVM_PPC_1T_SEGMENTS,
+ },
};
/* PPC970/G5 */
-static u32 g5_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc, 0x0, 0x18, 0x100, 0x1,
0x18, 0x0};
-
static struct cpu_info cpu_970_info = {
.name = "G5",
- .page_sizes_prop = g5_page_sizes_prop,
- .page_sizes_prop_len = sizeof(g5_page_sizes_prop),
.segment_sizes_prop = NULL /* no segment sizes prop, use defaults */,
.segment_sizes_prop_len = 0,
.slb_size = 0,
@@ -72,6 +66,118 @@ static struct pvr_info host_pvr_info[] = {
{ 0x, 0x0045, &cpu_970_info },
};
+/* If we can't query the kernel for supported page sizes assume 4K and 16M */
+static struct kvm_ppc_one_seg_page_size fallback_sps[] = {
+ [0] = {
+ .page_shift = 12,
+ .slb_enc= 0,
+ .enc = {
+ [0] = {
+ .page_shift = 12,
+ .pte_enc= 0,
+ },
+ },
+ },
+ [1] = {
+ .page_shift = 24,
+ .slb_enc= 0x100,
+ .enc = {
+ [0] = {
+ .page_shift = 24,
+ .pte_enc= 0,
+ },
+ },
+ },
+};
+
+
+static void setup_mmu_info(struct kvm *kvm, struct cpu_info *cpu_info)
+{
+ static struct kvm_ppc_smmu_info *mmu_info;
+ struct kvm_ppc_one_seg_page_size *sps;
+ int i, j, k, valid;
+
+ if (!kvm__supports_extension(kvm, KVM_CAP_PPC_GET_SMMU_INFO)) {
+ memcpy(&cpu_info->mmu_info.sps, fallback_sps,
sizeof(fallback_sps));
+ } else if (ioctl(kvm->vm_fd, KVM_PPC_GET_SMMU_INFO,
&cpu_info->mmu_info) < 0) {
+ die_perror("KVM_PPC_GET_SMMU_INFO failed");
+ }
+
+ mmu_info = &cpu_info->mmu_info;
+
+ if (!(mmu_info->flags & KVM_PPC_PAGE_SIZES_REAL))
+ /* Guest pages are not restricted by the backing page size */
+ return;
+
+ /* Filter based on backing page size */
+
+ for (i = 0; i < KVM_PPC_PAGE_SIZES_MAX_SZ; i++) {
+ sps = &mmu_info->sps[i];
+
+ if (!sps->page_shift)
+ break;
+
+ if (kvm->ram_pagesize < (1ul << sps->page_shift)) {
+ /* Mark the whole segment size invalid */
+ sps->page_shift = 0;
+ continue;
+ }
+
+ /* Check each page size for the segment */
+ for (j = 0, valid = 0; j < KVM_PPC_PAGE_SIZES_MAX_SZ; j++) {
+ if (!sps->enc[j].page_shift)
+ break;
+
+ if (kvm->ram_pagesize < (1ul << sps->enc[j].page
[PATCH 05/10] kvm tools, powerpc: Use ARRAY_SIZE() in find_cpu_info()
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index ad27451..7326f5b 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -75,7 +75,7 @@ static struct pvr_info host_pvr_info[] = {
struct cpu_info *find_cpu_info(u32 pvr)
{
unsigned int i;
- for (i = 0; i < sizeof(host_pvr_info)/sizeof(struct pvr_info); i++) {
+ for (i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
if ((pvr & host_pvr_info[i].pvr_mask) ==
host_pvr_info[i].pvr) {
return host_pvr_info[i].cpu_info;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] kvm tools: Remember page size as kvm->ram_pagesize
On some powerpc platforms we need to make sure we only advertise page
sizes to the guest which are <= the size of the pages backing guest RAM.
So have mmap_hugetblfs() save the hugetblfs page size for us, and also
teach mmap_anon_or_hugetblfs() to set the page size for anonymous mmap.
Signed-off-by: Michael Ellerman
---
tools/kvm/include/kvm/util.h |4 +++-
tools/kvm/powerpc/include/kvm/kvm-arch.h |1 +
tools/kvm/powerpc/kvm.c |2 +-
tools/kvm/util/util.c| 13 +
tools/kvm/x86/include/kvm/kvm-arch.h |1 +
tools/kvm/x86/kvm.c |4 ++--
6 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/tools/kvm/include/kvm/util.h b/tools/kvm/include/kvm/util.h
index 3d1d987..0df9f0d 100644
--- a/tools/kvm/include/kvm/util.h
+++ b/tools/kvm/include/kvm/util.h
@@ -90,6 +90,8 @@ static inline void msleep(unsigned int msecs)
usleep(MSECS_TO_USECS(msecs));
}
-void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size);
+struct kvm;
+void *mmap_hugetlbfs(struct kvm *kvm, const char *htlbfs_path, u64 size);
+void *mmap_anon_or_hugetlbfs(struct kvm *kvm, const char *hugetlbfs_path, u64
size);
#endif /* KVM__UTIL_H */
diff --git a/tools/kvm/powerpc/include/kvm/kvm-arch.h
b/tools/kvm/powerpc/include/kvm/kvm-arch.h
index 404e33e..316fe79 100644
--- a/tools/kvm/powerpc/include/kvm/kvm-arch.h
+++ b/tools/kvm/powerpc/include/kvm/kvm-arch.h
@@ -54,6 +54,7 @@ struct kvm {
u64 ram_size;
void*ram_start;
+ u64 ram_pagesize;
u64 sdr1;
u32 pvr;
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index 0d8a9da..e3a7e52 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -101,7 +101,7 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
if (hugetlbfs_path && !strcmp(hugetlbfs_path, "default"))
hugetlbfs_path = HUGETLBFS_PATH;
- kvm->ram_start = mmap_anon_or_hugetlbfs(hugetlbfs_path, kvm->ram_size);
+ kvm->ram_start = mmap_anon_or_hugetlbfs(kvm, hugetlbfs_path,
kvm->ram_size);
if (kvm->ram_start == MAP_FAILED)
die("Couldn't map %lld bytes for RAM (%d)\n",
diff --git a/tools/kvm/util/util.c b/tools/kvm/util/util.c
index a80cf86..c11a15a 100644
--- a/tools/kvm/util/util.c
+++ b/tools/kvm/util/util.c
@@ -4,6 +4,7 @@
#include "kvm/util.h"
+#include
#include/* For HUGETLBFS_MAGIC */
#include
#include
@@ -80,7 +81,7 @@ void die_perror(const char *s)
exit(1);
}
-void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
+void *mmap_hugetlbfs(struct kvm *kvm, const char *htlbfs_path, u64 size)
{
char mpath[PATH_MAX];
int fd;
@@ -100,6 +101,8 @@ void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
blk_size, size);
}
+ kvm->ram_pagesize = blk_size;
+
snprintf(mpath, PATH_MAX, "%s/kvmtoolXX", htlbfs_path);
fd = mkstemp(mpath);
if (fd < 0)
@@ -115,14 +118,16 @@ void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
}
/* This function wraps the decision between hugetlbfs map (if requested) or
normal mmap */
-void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size)
+void *mmap_anon_or_hugetlbfs(struct kvm *kvm, const char *hugetlbfs_path, u64
size)
{
if (hugetlbfs_path)
/*
* We don't /need/ to map guest RAM from hugetlbfs, but we do so
* if the user specifies a hugetlbfs path.
*/
- return mmap_hugetlbfs(hugetlbfs_path, size);
- else
+ return mmap_hugetlbfs(kvm, hugetlbfs_path, size);
+ else {
+ kvm->ram_pagesize = getpagesize();
return mmap(NULL, size, PROT_RW, MAP_ANON_NORESERVE, -1, 0);
+ }
}
diff --git a/tools/kvm/x86/include/kvm/kvm-arch.h
b/tools/kvm/x86/include/kvm/kvm-arch.h
index 551c8b4..dd385d4 100644
--- a/tools/kvm/x86/include/kvm/kvm-arch.h
+++ b/tools/kvm/x86/include/kvm/kvm-arch.h
@@ -34,6 +34,7 @@ struct kvm {
u64 ram_size;
void*ram_start;
+ u64 ram_pagesize;
boolnmi_disabled;
diff --git a/tools/kvm/x86/kvm.c b/tools/kvm/x86/kvm.c
index 8931639..0a40fd5 100644
--- a/tools/kvm/x86/kvm.c
+++ b/tools/kvm/x86/kvm.c
@@ -144,9 +144,9 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
if (ram_size < KVM_32BIT_GAP_START) {
kvm->ram_size = ram_size;
- kvm->ram_start = mmap_anon_or_hugetlbfs(hugetlbfs_path,
ram_size);
+ kvm->ram_start = mmap_anon_or_hugetlbfs(kvm, hugetlbfs_path,
ram_size);
} else {
- kvm->ram_start = mmap_anon_or_hugetlbfs(hugetlbfs_p
[PATCH 01/10] kvm tools: Move mmap_anon_or_hugetblfs() into util
So we can use it on powerpc.
Signed-off-by: Michael Ellerman
---
tools/kvm/include/kvm/util.h |2 +-
tools/kvm/util/util.c| 13 +
tools/kvm/x86/kvm.c | 13 -
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/kvm/include/kvm/util.h b/tools/kvm/include/kvm/util.h
index dabf544..3d1d987 100644
--- a/tools/kvm/include/kvm/util.h
+++ b/tools/kvm/include/kvm/util.h
@@ -90,6 +90,6 @@ static inline void msleep(unsigned int msecs)
usleep(MSECS_TO_USECS(msecs));
}
-void *mmap_hugetlbfs(const char *htlbfs_path, u64 size);
+void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size);
#endif /* KVM__UTIL_H */
diff --git a/tools/kvm/util/util.c b/tools/kvm/util/util.c
index e7feebc..a80cf86 100644
--- a/tools/kvm/util/util.c
+++ b/tools/kvm/util/util.c
@@ -113,3 +113,16 @@ void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
return addr;
}
+
+/* This function wraps the decision between hugetlbfs map (if requested) or
normal mmap */
+void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size)
+{
+ if (hugetlbfs_path)
+ /*
+* We don't /need/ to map guest RAM from hugetlbfs, but we do so
+* if the user specifies a hugetlbfs path.
+*/
+ return mmap_hugetlbfs(hugetlbfs_path, size);
+ else
+ return mmap(NULL, size, PROT_RW, MAP_ANON_NORESERVE, -1, 0);
+}
diff --git a/tools/kvm/x86/kvm.c b/tools/kvm/x86/kvm.c
index 10a1212..8931639 100644
--- a/tools/kvm/x86/kvm.c
+++ b/tools/kvm/x86/kvm.c
@@ -128,19 +128,6 @@ void kvm__arch_set_cmdline(char *cmdline, bool video)
strcat(cmdline, " console=ttyS0 earlyprintk=serial
i8042.noaux=1");
}
-/* This function wraps the decision between hugetlbfs map (if requested) or
normal mmap */
-static void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size)
-{
- if (hugetlbfs_path)
- /*
-* We don't /need/ to map guest RAM from hugetlbfs, but we do so
-* if the user specifies a hugetlbfs path.
-*/
- return mmap_hugetlbfs(hugetlbfs_path, size);
- else
- return mmap(NULL, size, PROT_RW, MAP_ANON_NORESERVE, -1, 0);
-}
-
/* Architecture-specific KVM init */
void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: fix compile for OF && !COMMON_CLK
On Tuesday 17 July 2012 03:16 AM, Rob Herring wrote:
From: Rob Herring
With commit 766e6a4ec602d0c107 (clk: add DT clock binding support),
compiling with OF&& !COMMON_CLK is broken.
Thanks Rob!!
This patch fixed the build failure for Tegra.
Reported-by: Alexandre Pereira da Silva
Reported-by: Prashant Gaikwad
Signed-off-by: Rob Herring
---
drivers/clk/clkdev.c |2 +-
include/linux/clk.h |7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 20649b3..8f87b0f 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -24,7 +24,7 @@
static LIST_HEAD(clocks);
static DEFINE_MUTEX(clocks_mutex);
-#ifdef CONFIG_OF
+#if defined(CONFIG_OF)&& defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index)
{
struct of_phandle_args clkspec;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 8b70342..35f7492 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -12,6 +12,7 @@
#ifndef __LINUX_CLK_H
#define __LINUX_CLK_H
+#include
#include
#include
@@ -313,19 +314,19 @@ int clk_add_alias(const char *alias, const char
*alias_dev_name, char *id,
struct device_node;
struct of_phandle_args;
-#ifdef CONFIG_OF
+#if defined(CONFIG_OF)&& defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
#else
static inline struct clk *of_clk_get(struct device_node *np, int index)
{
- return NULL;
+ return ERR_PTR(-EINVAL);
}
static inline struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
{
- return NULL;
+ return ERR_PTR(-EINVAL);
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci: EHCI/xHCI ports switching on Intense-PC.
On Mon, Jul 16, 2012 at 07:46:06PM +0300, Denis Turischev wrote:
> Intense-PC is Compulab's mini-desktop with Intel Panther Point
> chipset.
>
> Unconditional ports switching provided by function
> usb_enable_xhci_ports() leads to surprising results, after shutdown
> system powered-on again after a few seconds. On Windows power
> related problems were not observed.
Do you have wake on lan enabled in the BIOS? I have heard reports from
other users that this is a BIOS bug triggered by WOL.
> The patch avoids ports switching for Intense-PC.
>
> Signed-off-by: Denis Turischev
> ---
> drivers/usb/host/pci-quirks.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index df0828c..6f72593 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -759,6 +759,13 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
> {
> u32 ports_available;
>
> + const char *brd_name;
> + brd_name = dmi_get_system_info(DMI_BOARD_NAME);
> +
> + /* quirk for Compulab's Intense-PC board */
> + if (brd_name && strstr(brd_name, "Intense-PC"))
> + return;
> +
No, this fix is not acceptable. You won't get USB 3.0 speeds if the
ports are not switched over. Now, we can add a quirk to the xHCI
shutdown function to switch the ports back to EHCI on shutdown. That
might not trigger the BIOS bug.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH mmotm] memcg: further prevent OOM with too many dirty pages
On Mon, 16 Jul 2012, Michal Hocko wrote: > On Mon 16-07-12 01:35:34, Hugh Dickins wrote: > > But even so, the test still OOMs sometimes: when originally testing > > on 3.5-rc6, it OOMed about one time in five or ten; when testing > > just now on 3.5-rc6-mm1, it OOMed on the first iteration. > > > > This residual problem comes from an accumulation of pages under > > ordinary writeback, not marked PageReclaim, so rightly not causing > > the memcg check to wait on their writeback: these too can prevent > > shrink_page_list() from freeing any pages, so many times that memcg > > reclaim fails and OOMs. > > I guess you managed to trigger this with 20M limit, right? That's right. > I have tested > with different group sizes but the writeback didn't trigger for most of > them and all the dirty data were flushed from the reclaim. I didn't examine writeback stats to confirm, but I guess that just occasionally it managed to come in and do enough work to confound us. > Have you used any special setting the dirty ratio? No, I wasn't imaginative enough to try that. > Or was it with xfs (IIUC that one > does ignore writeback from the direct reclaim completely). No, just ext4 at that point. I have since tested the final patch with ext4, ext3 (by ext3 driver and by ext4 driver), ext2 (by ext2 driver and by ext4 driver), xfs, btrfs, vfat, tmpfs (with swap on the USB stick) and block device: about an hour on each, no surprises, all okay. But I didn't experiment beyond the 20M memcg. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/17 12:32, Wen Congyang wrote:
> At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 11:32, Wen Congyang wrote:
>>> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/17 10:44, Yasuaki Ishimatsu wrote:
> Hi Wen,
>
> 2012/07/13 12:35, Wen Congyang wrote:
>> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
>>> acpi_memory_device_remove() has been prepared to remove physical memory.
>>> But, the function only frees acpi_memory_device currentlry.
>>>
>>> The patch adds following functions into acpi_memory_device_remove():
>>> - offline memory
>>> - remove physical memory (only return -EBUSY)
>>> - free acpi_memory_device
>>>
>>> CC: David Rientjes
>>> CC: Jiang Liu
>>> CC: Len Brown
>>> CC: Benjamin Herrenschmidt
>>> CC: Paul Mackerras
>>> CC: Christoph Lameter
>>> Cc: Minchan Kim
>>> CC: Andrew Morton
>>> CC: KOSAKI Motohiro
>>> CC: Wen Congyang
>>> Signed-off-by: Yasuaki Ishimatsu
>>>
>>> ---
>>> drivers/acpi/acpi_memhotplug.c | 26 +-
>>> drivers/base/memory.c | 39
>>> +++
>>> include/linux/memory.h |5 +
>>> include/linux/memory_hotplug.h |1 +
>>> mm/memory_hotplug.c|8
>>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>>
>>> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
>>> ===
>>> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
>>> 18:08:29.946888653 +0900
>>> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c2012-07-09
>>> 18:08:43.470719531 +0900
>>> @@ -29,6 +29,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
>>> static int acpi_memory_device_remove(struct acpi_device *device,
>>> int type)
>>> {
>>> struct acpi_memory_device *mem_device = NULL;
>>> -
>>> + struct acpi_memory_info *info, *tmp;
>>> + int result;
>>> + int node;
>>>
>>> if (!device || !acpi_driver_data(device))
>>> return -EINVAL;
>>>
>>> mem_device = acpi_driver_data(device);
>>> +
>>> + node = acpi_get_node(mem_device->device->handle);
>>> +
>>> + list_for_each_entry_safe(info, tmp, &mem_device->res_list,
>>> list) {
>>> + if (!info->enabled)
>>> + continue;
>>> +
>>> + if (!is_memblk_offline(info->start_addr, info->length))
>>> {
>>> + result = offline_memory(info->start_addr,
>>> info->length);
>>> + if (result)
>>> + return result;
>>> + }
>>> +
>>> + result = remove_memory(node, info->start_addr,
>>> info->length);
>>
>> The user may online the memory between offline_memory() and
>> remove_memory().
>> So I think we should lock memory hotplug before check the memory's status
>> and release it after remove_memory().
>
> How about get "mem_block->state_mutex" of removed memory? When offlining
> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
> In this case, we get mem_block->state_mutex. So I think the mutex lock
> is beneficial.
It is not good idea since remove_memory frees mem_block structure...
Do you have any ideas?
>>>
>>> Hmm, split offline_memory() to 2 functions: offline_pages() and
>>> __offline_pages()
>>>
>>> offline_pages()
>>> lock_memory_hotplug();
>>> __offline_pages();
>>> unlock_memory_hotplug();
>>>
>>> and implement remove_memory() like this:
>>> remove_memory()
>>> lock_memory_hotplug()
>>> if (!is_memblk_offline()) {
>>> __offline_pages();
>>> }
>>> // cleanup
>>> unlock_memory_hotplug();
>>>
>>> What about this?
>>
>> I also thought about it once. But a problem remains. Current offilne_pages()
>> cannot realize the memory has been removed by remove_memory(). So even if
>> protecting the race by lock_memory_hotplug(), offline_pages() can offline
>> the removed memory. offline_pages() should have the means to know the memory
>> was removed. But I don't have good idea.
>
> We can not online/offline part of memory block, so what about this?
It seems you do not understand my concern.
When memory_remove() and offline_pages() run to same memory simultaneously,
offline_pages runs to removed memory.
memory_remove() | offline_pages()
-
Re: [PATCH V2 1/6] mfd: tps6586x:use devm managed resources
On Tuesday 17 July 2012 01:31 AM, Mark Brown wrote: On Mon, Jul 16, 2012 at 12:21:45PM +0530, Laxman Dewangan wrote: - ret = request_threaded_irq(irq, NULL, tps6586x_irq, IRQF_ONESHOT, - "tps6586x", tps6586x); + ret = devm_request_threaded_irq(tps6586x->dev, irq, NULL, tps6586x_irq, + IRQF_ONESHOT, "tps6586x", tps6586x); Are you sure this is safe - what guarantees that we can't get an interrupt while tearing the device down? I think device_remove will get called before the managed resource get freed. So do we need to call disable_irq() in remove() to avoid any interrupts? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Commit 6016af "[media] v4l2: use __u32 rather than enums in ioctl() structs" breaks C++ users of V4L2
Le lundi 16 juillet 2012 23:40:01 Jason L Tibbitts III, vous avez écrit :
> I ran into problems compiling the program ZoneMinder on Fedora rawhide
> (currently using something around 3.5rc6) which do not appear with 3.4
> kernels. With help this was traced to commit
> 6016af82eafcb6e086a8f2a2197b46029a843d68, "[media] v4l2: use __u32
> rather than enums in ioctl() structs" which changed videodev2.h in a way
> which appears to be incompatible with C++.
>
> This results in code such as the following:
> enum v4l2_buf_type type = v4l2_data.fmt.type;
That code is dangerous, probably even more so in C++. If the running kernel
version is more recent than the kernel header version that userland was
compiled with, the field value could be outside the range of the enumeration.
> failing to compile with:
> zm_local_camera.cpp:1523:49: error: invalid conversion from '__u32
> {aka unsigned int}' to 'v4l2_buf_type' [-fpermissive]
> but only when compiled with the headers from a 3.5 kernel.
>
> I'm very far from a C++ expert. I talked with some people who do grok
> it and the issue comes down to restrictions on assignments of ints to
> enums
> and additionally that enums in C++ don't have defined size.
That cannot be true. Your C++ compiler must agree with the kernel's C compiler
on the size of enum. If they did not, V4L2 would not have ever worked from C++
code in previous kernel versions.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 82571EB: Detected Hardware Unit Hang
On Mon, Jul 16, 2012 at 9:08 AM, Henrique de Moraes Holschuh wrote: > On Mon, 16 Jul 2012, Ben Hutchings wrote: >> On Sun, 2012-07-15 at 10:35 -0300, Henrique de Moraes Holschuh wrote: >> > On Sun, 15 Jul 2012, Dave, Tushar N wrote: >> > > Somehow setting max payload to 256 from BIOS does not set this value for >> > > all devices. I believe this is a BIOS bug. >> > >> > And preferably, Linux should complain about it. Since we know it is going >> > to cause problems, and since we know it does happen, we should be raising a >> > ruckus about it in the kernel log (and probably fixing it to min(path) >> > while >> > at it)... >> > >> > Is this something that should be raised as a feature request with the >> > PCI/PCIe subsystem? >> >> The feature is there, but we ended up with: >> >> commit 5f39e6705faade2e89d119958a8c51b9b6e2c53c >> Author: Jon Mason >> Date: Mon Oct 3 09:50:20 2011 -0500 >> >> PCI: Disable MPS configuration by default >> >> But you are welcome to share use of the fixup_mpss_256() quirk. > > Meh. I'd be happy with a warning if MPSS decreases when walking up to > the tree root... i.e. a warning if any child has a MPSS larger than the > parent. You can add "pci=pcie_bus_safe" to the kernel params and it should resolve your issue. > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Tue, 2012-07-17 at 00:34 -0400, Steven Rostedt wrote: > On Tue, 2012-07-17 at 00:27 -0400, Steven Rostedt wrote: > > > Actually, I was mistaken. I forgot that we defined 'cpu_chill()' as > > msleep(1) on RT, which would keep a deadlock from happening. > > Perhaps cpu_chill() isn't a good name, as it doesn't really explain what > is happening. Perhaps one of the following? > > cpu_rest() > cpu_sleep() > cpu_deep_relax() > cpu_dream() > cpu_hypnotize() ( cpu_waste_truckloads_of_time();) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 82571EB: Detected Hardware Unit Hang
On Mon, Jul 16, 2012 at 8:47 AM, Ben Hutchings wrote: > On Sun, 2012-07-15 at 10:35 -0300, Henrique de Moraes Holschuh wrote: >> On Sun, 15 Jul 2012, Dave, Tushar N wrote: >> > Somehow setting max payload to 256 from BIOS does not set this value for >> > all devices. I believe this is a BIOS bug. >> >> And preferably, Linux should complain about it. Since we know it is going >> to cause problems, and since we know it does happen, we should be raising a >> ruckus about it in the kernel log (and probably fixing it to min(path) while >> at it)... >> >> Is this something that should be raised as a feature request with the >> PCI/PCIe subsystem? > > The feature is there, but we ended up with: > > commit 5f39e6705faade2e89d119958a8c51b9b6e2c53c > Author: Jon Mason > Date: Mon Oct 3 09:50:20 2011 -0500 > > PCI: Disable MPS configuration by default With the quirk, it should work now if pcie_bus_config is set to PCIE_BUS_SAFE. With that patch was pushed it was too late in the release to fix it and see if there were any other ones out there (or incur the wrath of Linus). If you are brave enough, you can enable it by default again and see if there are any other quirks out there. ;-) > But you are welcome to share use of the fixup_mpss_256() quirk. > > Ben. > > -- > Ben Hutchings, Staff Engineer, Solarflare > Not speaking for my employer; that's the marketing department's job. > They asked us to note that Solarflare product names are trademarked. > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Tue, 2012-07-17 at 00:27 -0400, Steven Rostedt wrote: > On Tue, 2012-07-17 at 06:18 +0200, Mike Galbraith wrote: > > > > > There's that too. But the issue I was talking about is with all trylock > > > loops. As holding an rt-mutex now disables migration, if a high priority > > > process preempts a task that holds the lock, and then the high prio task > > > starts spinning waiting for that lock to release, the lower priority > > > process will never get to run to release it. The cpu_chill() doesn't > > > help. > > > > Hrm. I better go make a testcase, this one definitely wants pounding > > through thick skull. > > Actually, I was mistaken. I forgot that we defined 'cpu_chill()' as > msleep(1) on RT, which would keep a deadlock from happening. Whew! There are no stars and moons on my pointy hat, just plain white cone, so you had me worried I was missing something critical there. > It doesn't explain the performance enhancement you get :-/ No, it doesn't. The only thing I can think of is that while folks are timed sleeping, they aren't preempting and interleaving IO as much, but I'm pulling that out of thin air. Timed sleep should be a lot longer than regular wakeup, so to my mind, there should be less interleave due to more thumb twiddling. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Rename CAP_EPOLLWAKEUP to CAL_BLOCK_SUSPEND
Rafael,
As discussed in
http://thread.gmane.org/gmane.linux.kernel/1249726/focus=1288990,
the capability introduced in 4d7e30d98939a0340022ccd49325a3d70f7e0238
to govern EPOLLWAKEUP seems misnamed: this capability is about governing
the ability to suspend the system, not using a particular API flag
(EPOLLWAKEUP). We should make the name of the capability more general
to encourage reuse in related cases. (Whether or not this capability
should also be used to govern the use of /sys/power/wake_lock is a
question that needs to be separately resolved.)
This patch renames the capability to CAP_BLOCK_SUSPEND. In order to ensure
that the old capability name doesn't make it out into the wild, could you
please apply and push up the tree to ensure that it is incorporated
for the 3.5 release.
Thanks,
Michael
Signed-off-by: Michael Kerrisk
---
fs/eventpoll.c |2 +-
include/linux/capability.h |6 +++---
include/linux/eventpoll.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 74598f6..1c8b556 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1710,7 +1710,7 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
goto error_tgt_fput;
/* Check if EPOLLWAKEUP is allowed */
- if ((epds.events & EPOLLWAKEUP) && !capable(CAP_EPOLLWAKEUP))
+ if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
epds.events &= ~EPOLLWAKEUP;
/*
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 68d56ef..d10b7ed 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -360,11 +360,11 @@ struct cpu_vfs_cap_data {
#define CAP_WAKE_ALARM35
-/* Allow preventing system suspends while epoll events are pending */
+/* Allow preventing system suspends */
-#define CAP_EPOLLWAKEUP 36
+#define CAP_BLOCK_SUSPEND36
-#define CAP_LAST_CAP CAP_EPOLLWAKEUP
+#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
index 6f8be32..f4bb378 100644
--- a/include/linux/eventpoll.h
+++ b/include/linux/eventpoll.h
@@ -34,7 +34,7 @@
* re-allowed until epoll_wait is called again after consuming the wakeup
* event(s).
*
- * Requires CAP_EPOLLWAKEUP
+ * Requires CAP_BLOCK_SUSPEND
*/
#define EPOLLWAKEUP (1 << 29)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/6] mfd: tps6586x: cache register through regmap
On Tuesday 17 July 2012 01:33 AM, Mark Brown wrote: * PGP Signed by an unknown key On Mon, Jul 16, 2012 at 12:21:47PM +0530, Laxman Dewangan wrote: To cache the interrupt mask register, use the regmap RB_TREE cache-ing mechanism in place of implementing it locally. Reviewed-by: Mark Brown Can you use regmap-irq? Sure, I will convert it to regmap_irq and will send new patch after this series in linux-next. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Tue, 2012-07-17 at 00:27 -0400, Steven Rostedt wrote: > Actually, I was mistaken. I forgot that we defined 'cpu_chill()' as > msleep(1) on RT, which would keep a deadlock from happening. Perhaps cpu_chill() isn't a good name, as it doesn't really explain what is happening. Perhaps one of the following? cpu_rest() cpu_sleep() cpu_deep_relax() cpu_dream() cpu_hypnotize() -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 MUIC device
This patch support Maxim MAX77693 MUIC device by using EXTCON Subsystem to handle various external connector. The extcon-max77693 use regmap method for i2c communication and support irq domain instead of previous method of irq base. Signed-off-by: Chanwoo Choi Signed-off-by: Myungjoo Ham Signed-off-by: Kyungmin Park --- drivers/extcon/Kconfig | 10 + drivers/extcon/Makefile |1 + drivers/extcon/extcon-max77693.c | 779 ++ 3 files changed, 790 insertions(+), 0 deletions(-) create mode 100644 drivers/extcon/extcon-max77693.c diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index bb385ac..1671635 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -21,6 +21,16 @@ config EXTCON_GPIO Say Y here to enable GPIO based extcon support. Note that GPIO extcon supports single state per extcon instance. +config EXTCON_MAX77693 + tristate "MAX77693 EXTCON Support" + depends on MFD_MAX77693 + select IRQ_DOMAIN + select REGMAP_I2C + help + If you say yes here you get support for the MUIC device of + Maxim MAX77693 PMIC. The MAX77693 MUIC is a USB port accessory + detector and switch. + config EXTCON_MAX8997 tristate "MAX8997 EXTCON Support" depends on MFD_MAX8997 diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile index e932caa..88961b3 100644 --- a/drivers/extcon/Makefile +++ b/drivers/extcon/Makefile @@ -4,5 +4,6 @@ obj-$(CONFIG_EXTCON) += extcon_class.o obj-$(CONFIG_EXTCON_GPIO) += extcon_gpio.o +obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c new file mode 100644 index 000..920a609 --- /dev/null +++ b/drivers/extcon/extcon-max77693.c @@ -0,0 +1,779 @@ +/* + * extcon-max77693.c - MAX77693 extcon driver to support MAX77693 MUIC + * + * Copyright (C) 2012 Samsung Electrnoics + * Chanwoo Choi + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineDEV_NAME"max77693-muic" + +/* MAX77693 MUIC - STATUS1~3 Register */ +#define STATUS1_ADC_SHIFT (0) +#define STATUS1_ADCLOW_SHIFT (5) +#define STATUS1_ADCERR_SHIFT (6) +#define STATUS1_ADC1K_SHIFT(7) +#define STATUS1_ADC_MASK (0x1f << STATUS1_ADC_SHIFT) +#define STATUS1_ADCLOW_MASK(0x1 << STATUS1_ADCLOW_SHIFT) +#define STATUS1_ADCERR_MASK(0x1 << STATUS1_ADCERR_SHIFT) +#define STATUS1_ADC1K_MASK (0x1 << STATUS1_ADC1K_SHIFT) + +#define STATUS2_CHGTYP_SHIFT (0) +#define STATUS2_CHGDETRUN_SHIFT(3) +#define STATUS2_DCDTMR_SHIFT (4) +#define STATUS2_DXOVP_SHIFT(5) +#define STATUS2_VBVOLT_SHIFT (6) +#define STATUS2_VIDRM_SHIFT(7) +#define STATUS2_CHGTYP_MASK(0x7 << STATUS2_CHGTYP_SHIFT) +#define STATUS2_CHGDETRUN_MASK (0x1 << STATUS2_CHGDETRUN_SHIFT) +#define STATUS2_DCDTMR_MASK(0x1 << STATUS2_DCDTMR_SHIFT) +#define STATUS2_DXOVP_MASK (0x1 << STATUS2_DXOVP_SHIFT) +#define STATUS2_VBVOLT_MASK(0x1 << STATUS2_VBVOLT_SHIFT) +#define STATUS2_VIDRM_MASK (0x1 << STATUS2_VIDRM_SHIFT) + +#define STATUS3_OVP_SHIFT (2) +#define STATUS3_OVP_MASK (0x1 << STATUS3_OVP_SHIFT) + +/* MAX77693 CDETCTRL1~2 register */ +#define CDETCTRL1_CHGDETEN_SHIFT (0) +#define CDETCTRL1_CHGTYPMAN_SHIFT (1) +#define CDETCTRL1_DCDEN_SHIFT (2) +#define CDETCTRL1_DCD2SCT_SHIFT(3) +#define CDETCTRL1_CDDELAY_SHIFT(4) +#define CDETCTRL1_DCDCPL_SHIFT (5) +#define CDETCTRL1_CDPDET_SHIFT (7) +#define CDETCTRL1_CHGDETEN_MASK(0x1 << CDETCTRL1_CHGDETEN_SHIFT) +#define CDETCTRL1_CHGTYPMAN_MASK (0x1 << CDETCTRL1_CHGTYPMAN_SHIFT) +#define CDETCTRL1_DCDEN_MASK (0x1 << CDETCTRL1_DCDEN_SHIFT) +#define CDETCTRL1_DCD2SCT_MASK (0x1 << CDETCTRL1_DCD2SCT_SHIFT) +#define CDETCTRL1_CDDELAY_MASK (0x1 << CDETCTRL1_CDDELAY_SHIFT) +#define CDETCTRL1_DCDCPL_MASK (0x1 << CDETCTRL1_DCDCPL_SHIFT) +#define CDETCTRL1_CDPDET_MASK (0x1 <
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Tue, 2012-07-17 at 06:18 +0200, Mike Galbraith wrote: > > > There's that too. But the issue I was talking about is with all trylock > > loops. As holding an rt-mutex now disables migration, if a high priority > > process preempts a task that holds the lock, and then the high prio task > > starts spinning waiting for that lock to release, the lower priority > > process will never get to run to release it. The cpu_chill() doesn't > > help. > > Hrm. I better go make a testcase, this one definitely wants pounding > through thick skull. Actually, I was mistaken. I forgot that we defined 'cpu_chill()' as msleep(1) on RT, which would keep a deadlock from happening. It doesn't explain the performance enhancement you get :-/ -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] USB: ehci-s5p: Add vbus setup function to the s5p ehci glue layer
This patch retrieves and configures the vbus control gpio via
the device tree. The suspend/resume callbacks will be later
modified for vbus control.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-s5p.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 37d84cf..9d8f1dd 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -64,6 +65,24 @@ static const struct hc_driver s5p_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static void s5p_setup_vbus_gpio(struct platform_device *pdev)
+{
+ int err;
+ int gpio;
+
+ if (!pdev->dev.of_node)
+ return;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node,
+ "samsung,vbus-gpio", 0);
+ if (!gpio_is_valid(gpio))
+ return;
+
+ err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
+ if (err)
+ dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
+}
+
static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
static int __devinit s5p_ehci_probe(struct platform_device *pdev)
@@ -92,6 +111,8 @@ static int __devinit s5p_ehci_probe(struct platform_device
*pdev)
if (!pdev->dev.coherent_dma_mask)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ s5p_setup_vbus_gpio(pdev);
+
s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
GFP_KERNEL);
if (!s5p_ehci)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] USB: host: Add Device tree support for ohci-exynos & ehci-s5p
Reworked third patch; other two got applied to 'usb-next' branch. Changes from v3: 1) Change the function name from s5p_ehci_setup_gpio() to s5p_setup_vbus_gpio(). 2) Make s5p_setup_vbus_gpio() function to return void instead of int. 3) Return void in case of failures. Vivek Gautam (1): USB: ehci-s5p: Add vbus setup function to the s5p ehci glue layer drivers/usb/host/ehci-s5p.c | 21 + 1 files changed, 21 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > [] > > @@ -13,6 +13,8 @@ > > * Copyright (C) 2004 William Lee Irwin III > > */ > > > > +#define pr_fmt(fmt) "ftrace: " fmt > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt Wouldn't a nicer patch be to move this into a header file and then remove all the defines throughout the kernel tree? Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is not a module. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Mon, 2012-07-16 at 13:03 -0400, Steven Rostedt wrote: > On Mon, 2012-07-16 at 18:36 +0200, Mike Galbraith wrote: > > > > > > Ouch, you just turned the rt_read_lock() into a spin lock. If a higher > > > > priority process preempted a lower priority process that holds the same > > > > lock, it will deadlock. > > > > > > Hm, how, it's doing cpu_chill()? > > > > 'course PI is toast, so *poof*. Since just enabling the lockdep bits > > seems to fix it up, maybe that's the patchlet to submit (less is more). > > There's that too. But the issue I was talking about is with all trylock > loops. As holding an rt-mutex now disables migration, if a high priority > process preempts a task that holds the lock, and then the high prio task > starts spinning waiting for that lock to release, the lower priority > process will never get to run to release it. The cpu_chill() doesn't > help. Hrm. I better go make a testcase, this one definitely wants pounding through thick skull. I think all of the chilling in patchlet is really ugly anyway, so would prefer to trash it all, just enable the lockdep bits. If it turns out we really do need to bounce off of counts, go get a bigger hammer when the need arises. For the nonce, the pre-installed hammer _seemed_ big enough for the job. What's a good way to beat living hell out of btrfs? I've never been into destructive fs testing, since they usually lived on my one and only disk. x3550 has two, and OS clone has already been sacrificed. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] mmc: block: Add write packing control
On Mon, Jul 16, 2012 at 8:16 AM, Chris Ball wrote: > Hi, > > On Sun, Jul 15 2012, Muthu Kumar wrote: >>> I've already replied to a later version of the patch, but just to get >>> this comment in at the appropriate point of the discussion as well: >>> >>> Even though it would result in a cleaner sysfs, I don't want to do >>> this now because it will break userspace scripts that are depending >>> on the current locations of these attributes. >> >> Maya is adding a new sysfs attribute with that patch. So, there should >> not be any user space stuff that depends on it. > > In the later patchset, Maya's "[PATCH v4 1/2] mmc: card: Move MMC > specific attributes to mmc sub-directory" moves the existing attributes > into the mmc/ directory. > > It's that move that I'm objecting to, rather than the creation of a new > directory -- although since we're going to leave the current attributes > where they are, it might not make sense to add the new directory. > > We'd be creating two places that people have to look for mmc-related > attributes, which is arguably less clean than having one place to look > even though it's mixed in with the other block device attributes. > It's better to normalise this eventually. It would be better if we create a duplicate sysfs entry within MMC, which is identical to the current block layer attribute. Then schedule the block layer attribute to be removed by, say, 3.9. [Add it to Documentation/feature-removal-schedule.txt] Since it is a MMC specific attribute, generic tools wouldn't depend on it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/15] Drivers: hv: Add KVP definitions for IP address injection
On Sat, Jul 14, K. Y. Srinivasan wrote:
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 68ed7f7..38b561a 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -127,6 +127,8 @@ enum hv_kvp_exchg_op {
> KVP_OP_SET,
> KVP_OP_DELETE,
> KVP_OP_ENUMERATE,
> + KVP_OP_GET_IP_INFO,
> + KVP_OP_SET_IP_INFO,
> KVP_OP_REGISTER,
> KVP_OP_COUNT /* Number of operations, must be last. */
> };
I think this will break the kernel/daemon API for existing binaries.
Perhaps a forward/backwards compatible API where an older binary
continues to work with a newer kernel should be added.
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
答复: [PATCH 7/13] USB:support the new interfaces of Huawei Data Card devices in option driver
Dear bjorn:
"Fangxiaozhi (Franko)" writes:
> From: fangxiaozhi
> 1. This patch is based on the kernel of 3.5-rc6
> 2. In this patch, we add new micro for matching the series USB devices with
> vendor ID and interface information.
> 3. In this patch, we add new declarations into option.c to support the new
> interfaces of Huawei Data Card devices.
> Signed-off-by: fangxiaozhi
> ---
> --- ../test/linux-3.5-rc6/include/linux/usb.h 2012-07-08 08:23:56.0
> +0800
> +++ include/linux/usb.h 2012-07-13 17:45:59.0 +0800
> @@ -828,6 +828,27 @@ static inline int usb_make_path(struct u
> .bInterfaceClass = (cl), \
> .bInterfaceSubClass = (sc), \
> .bInterfaceProtocol = (pr)
> +/**
> + * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a
> class of usb interfaces, but independent of product ID
This chunk seems like a copy of the patch Gustavo Padovan just
submitted? Should really be listed as a precondition instead of
included here, should it not?
-In your opinions, it is better to declare this defining in the option.c
file, but not usb.h file, right?
> --- ../test/linux-3.5-rc6/drivers/usb/serial/option.c 2012-07-13
> 14:22:52.0 +0800
> +++ drivers/usb/serial/option.c 2012-07-13 17:38:38.0 +0800
> @@ -572,6 +572,115 @@ static const struct option_blacklist_inf
> };
>
> static const struct usb_device_id option_ids[] = {
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) },
I guess this means that the device specific entries matching this could
and should be removed, does it not? All these seem redundant with your
patch:
--The new matching rule is independent of the special product ID, so it can
support a series products of Huawei Data Card.
-The following matching rule is only for the specific product, and it is
covered by the new matching rule, so I think that we can remove the following
matching sentences.
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x33) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x02) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x03) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x10) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x12) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x13) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x01) }, /* E398 3G Modem */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x02) }, /* E398 3G PC UI Interface */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x03) }, /* E398 3G Application Interface */
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x04) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x05) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x06) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0A) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0B) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0D) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI
[PATCH 2/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue. An else statement was
not on the same line as the preceding if statement's
closing brace.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index a3cb559..50be42a 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -826,8 +826,7 @@ int card_power_on(struct rts51x_chip *chip, u8 card)
if ((card == SD_CARD) || (card == XD_CARD)) {
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask | LDO3318_PWR_MASK,
val1 | LDO_SUSPEND);
- }
- else {
+ } else {
#endif
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask, val1);
#ifdef SD_XD_IO_FOLLOW_PWR
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index 4192c3b..a3cb559 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -211,13 +211,12 @@ static void card_cd_debounce(struct rts51x_chip *chip, u8
*need_reset,
release_map |= MS_CARD;
}
} else {
- if (chip->card_status & XD_CD) {
+ if (chip->card_status & XD_CD)
reset_map |= XD_CARD;
- } else if (chip->card_status & SD_CD) {
+ else if (chip->card_status & SD_CD)
reset_map |= SD_CARD;
- } else if (chip->card_status & MS_CD) {
+ else if (chip->card_status & MS_CD)
reset_map |= MS_CARD;
- }
}
if (CHECK_PKG(chip, QFN24) && reset_map) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 0] staging: rts5139: rts51x_card: coding style fix
I am resending this patch-set because the initial version's subject didn't include [PATCH 0]. This patch-set fixes coding style issues in rts51x_card driver. Issues were found with scripts/checkpatch.pl tool. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/tty/tty_ioctl.c: In function 'set_sgflags':
drivers/tty/tty_ioctl.c:741:9: error: request for member 'c_iflag' in something
not a structure or union
drivers/tty/tty_ioctl.c:742:9: error: request for member 'c_oflag' in something
not a structure or union
drivers/tty/tty_ioctl.c:743:9: error: request for member 'c_lflag' in something
not a structure or union
drivers/tty/tty_ioctl.c:745:10: error: request for member 'c_iflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:746:10: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:749:10: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:753:10: error: request for member 'c_oflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:756:10: error: request for member 'c_iflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:757:10: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:759:15: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:760:10: error: request for member 'c_cc' in something
not a structure or union
drivers/tty/tty_ioctl.c:761:10: error: request for member 'c_cc' in something
not a structure or union
Caused by commit adc8d746caa6 ("tty: move the termios object into the
tty"). Did anyone build test this? :-(
I have used the tty tree from next-20120712 again for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpY6lJ3X1WnY.pgp
Description: PGP signature
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 09:15 +0800, Jovi Zhang wrote:
> >From fe42b2f29e5968482b3129c71f81a58a0559cf04 Mon Sep 17 00:00:00 2001
[]
> There don't have subsystem name output in front ot ftrace related log entry,
> so use pr_fmt to enable better printk output, for output subsystem name in
> log entry.
Hi Jovi. A few things:
Your patch has 80 column wrapping issues and doesn't
apply cleanly.
This sort of patch, because it's trivial and not really
important to apply this close to an actual release, should
be done against linux-next not current mainline.
The #define pr_fmt(fmt) should probably use KBUILD_MODNAME.
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Please coalesce formats even though they then may exceed
80 columns and compress multiple lines that fit in 80 too.
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
[]
> @@ -13,6 +13,8 @@
> * Copyright (C) 2004 William Lee Irwin III
> */
>
> +#define pr_fmt(fmt) "ftrace: " fmt
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
[]
> @@ -2187,12 +2189,12 @@ static int __init
> ftrace_dyn_table_alloc(unsigned long num_to_init)
wrapped
> int cnt;
>
> if (!num_to_init) {
> - pr_info("ftrace: No functions to be traced?\n");
> + pr_info("No functions to be traced?\n");
> return -1;
> }
>
> cnt = num_to_init / ENTRIES_PER_PAGE;
> - pr_info("ftrace: allocating %ld entries in %d pages\n",
> + pr_info("allocating %ld entries in %d pages\n",
> num_to_init, cnt + 1);
Single line:
pr_info("allocating %ld entries in %d pages\n", num_to_init, cnt + 1);
> @@ -4495,7 +4497,7 @@ static int start_graph_tracing(void)
> if (!ret) {
> ret =
> register_trace_sched_switch(ftrace_graph_probe_sched_switch, NULL);
> if (ret)
> - pr_info("ftrace_graph: Couldn't activate tracepoint"
> + pr_info("Couldn't activate tracepoint"
> " probe to kernel_sched_switch\n");
Coalesce format:
pr_info("Couldn't activate tracepoint probe to
kernel_sched_switch\n");
etc...
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: staging: rts5139: rts51x_card: coding style fix
On 07/16/2012 10:52 PM, Erik Jones wrote: This patch-set fixes coding style issues in rts51x_card driver. Issues were found with scripts/checkpatch.pl tool. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Resubmitting with a [PATCH 0] in initial Reply-to message's subject. Please ignore this patch-set. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xfs: fix comment typo of struct xfs_da_blkinfo.
Hi Ben, On Jul 16, 2012, at 11:10 PM, Ben Myers wrote: > Hey Chen, > > On Sat, Jul 14, 2012 at 03:38:13AM +0800, Chen Baozi wrote: >> Fix trivial typo error that has written "It" to "Is". >> >> Signed-off-by: Chen Baozi > > Reviewed-by: Ben Myers > > Thanks for the patch! I'm happy you're working on XFS. Do you have any > time/interest in taking on a work item or two? I have a few would-be-nices > which I've made notes of, and I'm sure that Dave or Christoph could also think > of a few if you're interested. I'd really love to. Right now, I am working on syslinux to support booting on xfs partition (under pcacjr's mentoring)， which I thought would be a nice start to get familiar with xfs (and I did learn a lot from it). So I think there would be more time (and experience on xfs) after I finish the xfs support on syslinux. And I'm really looking forward to your ideas. So do please tell me what I can help, I'll try my best to do it. Thanks a lot. Baozi > > Thanks again, > -Ben > >> --- >> fs/xfs/xfs_da_btree.h |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/fs/xfs/xfs_da_btree.h b/fs/xfs/xfs_da_btree.h >> index dbf7c07..be30bd4 100644 >> --- a/fs/xfs/xfs_da_btree.h >> +++ b/fs/xfs/xfs_da_btree.h >> @@ -32,7 +32,7 @@ struct zone; >> /* >> * This structure is common to both leaf nodes and non-leaf nodes in the >> Btree. >> * >> - * Is is used to manage a doubly linked list of all blocks at the same >> + * It is used to manage a doubly linked list of all blocks at the same >> * level in the Btree, and to identify which type of block this is. >> */ >> #define XFS_DA_NODE_MAGIC0xfebe /* magic number: non-leaf blocks */ >> -- >> 1.7.1 >> >> ___ >> xfs mailing list >> x...@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFT] regulator: palmas: Fix calcuating selector in palmas_map_voltage_smps
The logic of calculating selector in palmas_map_voltage_smps() does not match
the logic to list voltage in palmas_list_voltage_smps().
We use below equation to calculate voltage when selector > 0:
voltage = (0.49V + (selector * 0.01V)) * RANGE
RANGE is either x1 or x2
So we need to take into account with the multiplier set in VSEL register when
calculating selector in palmas_map_voltage_smps()
Signed-off-by: Axel Lin
---
drivers/regulator/palmas-regulator.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 7540c95..17d19fb 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -373,11 +373,22 @@ static int palmas_set_voltage_smps_sel(struct
regulator_dev *dev,
static int palmas_map_voltage_smps(struct regulator_dev *rdev,
int min_uV, int max_uV)
{
+ struct palmas_pmic *pmic = rdev_get_drvdata(rdev);
+ int id = rdev_get_id(rdev);
int ret, voltage;
- ret = ((min_uV - 50) / 1) + 1;
- if (ret < 0)
- return ret;
+ if (min_uV == 0)
+ return 0;
+
+ if (pmic->range[id]) { /* RANGE is x2 */
+ if (min_uV < 100)
+ min_uV = 100;
+ ret = DIV_ROUND_UP(min_uV - 100, 2) + 1;
+ } else {/* RANGE is x1 */
+ if (min_uV < 50)
+ min_uV = 50;
+ ret = DIV_ROUND_UP(min_uV - 50, 1) + 1;
+ }
/* Map back into a voltage to verify we're still in bounds */
voltage = palmas_list_voltage_smps(rdev, ret);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/07/17 11:32, Wen Congyang wrote:
>> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
>>> Hi Wen,
>>>
>>> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
Hi Wen,
2012/07/13 12:35, Wen Congyang wrote:
> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
>> acpi_memory_device_remove() has been prepared to remove physical memory.
>> But, the function only frees acpi_memory_device currentlry.
>>
>> The patch adds following functions into acpi_memory_device_remove():
>> - offline memory
>> - remove physical memory (only return -EBUSY)
>> - free acpi_memory_device
>>
>> CC: David Rientjes
>> CC: Jiang Liu
>> CC: Len Brown
>> CC: Benjamin Herrenschmidt
>> CC: Paul Mackerras
>> CC: Christoph Lameter
>> Cc: Minchan Kim
>> CC: Andrew Morton
>> CC: KOSAKI Motohiro
>> CC: Wen Congyang
>> Signed-off-by: Yasuaki Ishimatsu
>>
>> ---
>> drivers/acpi/acpi_memhotplug.c | 26 +-
>> drivers/base/memory.c | 39
>> +++
>> include/linux/memory.h |5 +
>> include/linux/memory_hotplug.h |1 +
>> mm/memory_hotplug.c|8
>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>
>> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
>> ===
>> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c2012-07-09
>> 18:08:29.946888653 +0900
>> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
>> 18:08:43.470719531 +0900
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
>> static int acpi_memory_device_remove(struct acpi_device *device, int
>> type)
>> {
>> struct acpi_memory_device *mem_device = NULL;
>> -
>> +struct acpi_memory_info *info, *tmp;
>> +int result;
>> +int node;
>>
>> if (!device || !acpi_driver_data(device))
>> return -EINVAL;
>>
>> mem_device = acpi_driver_data(device);
>> +
>> +node = acpi_get_node(mem_device->device->handle);
>> +
>> +list_for_each_entry_safe(info, tmp, &mem_device->res_list,
>> list) {
>> +if (!info->enabled)
>> +continue;
>> +
>> +if (!is_memblk_offline(info->start_addr, info->length))
>> {
>> +result = offline_memory(info->start_addr,
>> info->length);
>> +if (result)
>> +return result;
>> +}
>> +
>> +result = remove_memory(node, info->start_addr,
>> info->length);
>
> The user may online the memory between offline_memory() and
> remove_memory().
> So I think we should lock memory hotplug before check the memory's status
> and release it after remove_memory().
How about get "mem_block->state_mutex" of removed memory? When offlining
memory, we need to change "memory_block->state" into "MEM_OFFLINE".
In this case, we get mem_block->state_mutex. So I think the mutex lock
is beneficial.
>>>
>>> It is not good idea since remove_memory frees mem_block structure...
>>> Do you have any ideas?
>>
>> Hmm, split offline_memory() to 2 functions: offline_pages() and
>> __offline_pages()
>>
>> offline_pages()
>> lock_memory_hotplug();
>> __offline_pages();
>> unlock_memory_hotplug();
>>
>> and implement remove_memory() like this:
>> remove_memory()
>> lock_memory_hotplug()
>> if (!is_memblk_offline()) {
>> __offline_pages();
>> }
>> // cleanup
>> unlock_memory_hotplug();
>>
>> What about this?
>
> I also thought about it once. But a problem remains. Current offilne_pages()
> cannot realize the memory has been removed by remove_memory(). So even if
> protecting the race by lock_memory_hotplug(), offline_pages() can offline
> the removed memory. offline_pages() should have the means to know the memory
> was removed. But I don't have good idea.
We can not online/offline part of memory block, so what about this?
remove_memory()
lock_memory_hotplug()
for each memory block:
if (!is_memblk_offline()) {
__offline_pages();
}
// cleanup
unlock_memory_hotplug();
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>> Thanks
>> Wen Congyang
>>>
>>> Thanks,
>>> Yasuaki Ishimatsu
>>>
Thanks,
Yasuaki Ishimatsu
Re: [PATCH] x86: revert "x86: Fix S4 regression"
Hi Cong,
When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump
kernel's panic in find_early_table_space().
init_memory_mapping: [mem 0x-0x36ffafff]
Kernel panic - not syncing: Cannot find space for the kernel page tables
Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17
Call Trace:
[] panic+0xb8/0x1c8
[] ? printk+0x48/0x4a
[] init_memory_mapping+0x46c/0x530
[] setup_arch+0x669/0xb0e
[] ? printk+0x48/0x4a
[] start_kernel+0x9b/0x34a
[] x86_64_start_reservations+0x131/0x136
[] x86_64_start_kernel+0xed/0xf4
In find_early_table_space(), a kernel tries to find free area below 512M
for pgtable using memblock_find_in_range, but it fails because kdump
kernel does not have enough free space below 512M due to the memmap
restriction. This is the memmap option specified against kdump kernel
when crashkernel=128M.
memmap=560K@64K memmap=130492K@770608K
Only 560KB area is available and it is not sufficient for pgtable (it
seems that about 1.8MB area is needed for pgtable). This problem is
fixed by your revert patch. I hope this patch gets merged.
Thanks,
Takao Indoh
(2012/06/12 14:21), Cong Wang wrote:
> From: Cong Wang
>
> This reverts the following commit:
>
> commit 8548c84da2f47e71bbbe300f55edb768492575f7
> Author: Takashi Iwai
> Date: Sun Oct 23 23:19:12 2011 +0200
>
> x86: Fix S4 regression
>
> Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a
> S4
> regression since 2.6.39, namely the machine reboots occasionally at
> S4
> resume. It doesn't happen always, overall rate is about 1/20. But,
> like other bugs, once when this happens, it continues to happen.
>
> This patch fixes the problem by essentially reverting the memory
> assignment in the older way.
>
> According to the previous discussion:
> http://marc.info/?l=linux-kernel&m=133161674120253&w=2
> it seems that so far the best solution is just reverting it.
>
> Takashi, could you help to test if the S4 regression is still
> there after this patch?
>
> Reported-by: CAI Qian
> Cc: Dave Young
> Cc: "H. Peter Anvin"
> Cc: Rafael J. Wysocki
> Cc: Yinghai Lu
> Cc: Takashi Iwai
> Signed-off-by: Cong Wang
>
> ---
> arch/x86/mm/init.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index bc4e9d8..7ab7975 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -74,8 +74,9 @@ static void __init find_early_table_space(struct map_range
> *mr, unsigned long en
> #ifdef CONFIG_X86_32
> /* for fixmap */
> tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
> -#endif
> +
> good_end = max_pfn_mapped << PAGE_SHIFT;
> +#endif
>
> base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
> if (!base)
>
[0.00] Linux version 3.5.0-rc6 (root@localhost) (gcc version 4.4.6
20120305 (Red Hat 4.4.6-4) (GCC) ) #17 SMP Thu Jul 12 13:49:46 JST 2012
[0.00] Command line: ro root=UUID=1893a13e-19af-439b-9d39-0a42260f3eaa
rd_NO_LUKS rd_NO_MD KEYBOARDTYPE=pc KEYTABLE=jp106 LANG=ja_JP.UTF-8 rd_NO_LVM
rd_NO_DM loglevel=7 earlyprintk=serial,ttyS0,19200n8 irqpoll nr_cpus=1
reset_devices cgroup_disable=memory mce=off memmap=exactmap memmap=560K@64K
memmap=130492K@770608K elfcorehdr=901100K memmap=64K$0K memmap=16K$624K
memmap=112K$912K memmap=32832K$3103360K memmap=40K#3136192K memmap=4K#3136232K
memmap=9492K$3136236K memmap=262144K$3670016K memmap=1024K$4173824K
memmap=4K$4175872K memmap=17408K$4176896K
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x0100-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbd69] usable
[0.00] BIOS-e820: [mem 0xbd6a-0xbf6a] reserved
[0.00] BIOS-e820: [mem 0xbf6b-0xbf6b9fff] ACPI data
[0.00] BIOS-e820: [mem 0xbf6ba000-0xbf6bafff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf6bb000-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfecf] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffa0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00043fff] usable
[0.00] bootconsole [earlyser0] enabled
[0.00] e820: last_pfn = 0x44 max_arch_pfn = 0x4
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0x] reserved
Re: [patch RT 1/3] cpu/rt: Rework cpu down for PREEMPT_RT
On Mon, 2012-07-16 at 08:07 +, Thomas Gleixner wrote:
I know you are on vacation (hope you are enjoying yourself ;-)
> ---
> include/linux/sched.h |7 ++
> kernel/cpu.c | 236
> +
> kernel/sched/core.c | 82 +-
> 3 files changed, 285 insertions(+), 40 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 7fc8321..777f7bb 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1973,6 +1973,10 @@ extern void do_set_cpus_allowed(struct task_struct *p,
>
> extern int set_cpus_allowed_ptr(struct task_struct *p,
> const struct cpumask *new_mask);
> +int migrate_me(void);
> +void tell_sched_cpu_down_begin(int cpu);
> +void tell_sched_cpu_down_done(int cpu);
> +
> #else
> static inline void do_set_cpus_allowed(struct task_struct *p,
> const struct cpumask *new_mask)
> @@ -1985,6 +1989,9 @@ static inline int set_cpus_allowed_ptr(struct
> task_struct *p,
> return -EINVAL;
> return 0;
> }
> +static inline int migrate_me(void) { return 0; }
> +static inline void tell_sched_cpu_down_begin(int cpu) { }
> +static inline void tell_sched_cpu_down_done(int cpu) { }
> #endif
>
> #ifndef CONFIG_CPUMASK_OFFSTACK
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index d79d33a..c5b3273 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -46,12 +46,7 @@ static int cpu_hotplug_disabled;
>
> static struct {
> struct task_struct *active_writer;
> -#ifdef CONFIG_PREEMPT_RT_FULL
> - /* Makes the lock keep the task's state */
> - spinlock_t lock;
> -#else
> struct mutex lock; /* Synchronizes accesses to refcount, */
> -#endif
> /*
>* Also blocks the new readers during
>* an ongoing cpu hotplug operation.
> @@ -67,20 +62,42 @@ static struct {
As I was backporting this to 3.0-rt, I noticed that the following is
needed too:
diff --git a/kernel/cpu.c b/kernel/cpu.c
index c5b3273..3e722c0 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -54,11 +54,7 @@ static struct {
int refcount;
} cpu_hotplug = {
.active_writer = NULL,
-#ifdef CONFIG_PREEMPT_RT_FULL
- .lock = __SPIN_LOCK_UNLOCKED(cpu_hotplug.lock),
-#else
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
-#endif
.refcount = 0,
};
As this goes with part of the applied patch above.
I'll add this on top, if no one objects.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
(2012/07/17 12:05), Steven Rostedt wrote: > On Tue, 2012-07-17 at 11:08 +0900, Masami Hiramatsu wrote: > >>> I found that regs_get_register() doesn't honor this either. Thus, >>> kprobes in tracing gets this: >>> >>> # echo 'p:ftrace sys_read+4 s=%sp' > /debug/tracing/kprobe_events >>> # echo 1 > /debug/tracing/events/kprobes/enable >>> # cat trace >>> sshd-1345 [000] d... 489.117168: ftrace: (sys_read+0x4/0x70) >>> s=b7e96768 >>> sshd-1345 [000] d... 489.117191: ftrace: (sys_read+0x4/0x70) >>> s=b7e96768 >>> cat-1447 [000] d... 489.117392: ftrace: (sys_read+0x4/0x70) >>> s=5a7 >>> cat-1447 [001] d... 489.118023: ftrace: (sys_read+0x4/0x70) >>> s=b77ad05f >>> less-1448 [000] d... 489.118079: ftrace: (sys_read+0x4/0x70) >>> s=b7762e06 >>> less-1448 [000] d... 489.118117: ftrace: (sys_read+0x4/0x70) >>> s=b7764970 >>> >> >> Yes, that is by design, since I made it so. :) >> Instead of %sp, kprobe tracer provides $stack special argument >> for stack address, because "sp" is not always means the stack >> address on every arch. > > But is that useful? Wouldn't the actual stack pointer be more > informative? It is just FYI :). I rather like your "%sp" enhancement than current meaningless "%sp" on i386... However, I think "$stack" is more general and informative for users, thus, at least perf probe uses it for getting variables from stack. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/17 11:32, Wen Congyang wrote:
> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
>>> Hi Wen,
>>>
>>> 2012/07/13 12:35, Wen Congyang wrote:
At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
> - offline memory
> - remove physical memory (only return -EBUSY)
> - free acpi_memory_device
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/acpi/acpi_memhotplug.c | 26 +-
> drivers/base/memory.c | 39
> +++
> include/linux/memory.h |5 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c|8
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
> ===
> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:29.946888653 +0900
> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:43.470719531 +0900
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
> static int acpi_memory_device_remove(struct acpi_device *device, int
> type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + struct acpi_memory_info *info, *tmp;
> + int result;
> + int node;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + node = acpi_get_node(mem_device->device->handle);
> +
> + list_for_each_entry_safe(info, tmp, &mem_device->res_list, list) {
> + if (!info->enabled)
> + continue;
> +
> + if (!is_memblk_offline(info->start_addr, info->length)) {
> + result = offline_memory(info->start_addr, info->length);
> + if (result)
> + return result;
> + }
> +
> + result = remove_memory(node, info->start_addr, info->length);
The user may online the memory between offline_memory() and
remove_memory().
So I think we should lock memory hotplug before check the memory's status
and release it after remove_memory().
>>>
>>> How about get "mem_block->state_mutex" of removed memory? When offlining
>>> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
>>> In this case, we get mem_block->state_mutex. So I think the mutex lock
>>> is beneficial.
>>
>> It is not good idea since remove_memory frees mem_block structure...
>> Do you have any ideas?
>
> Hmm, split offline_memory() to 2 functions: offline_pages() and
> __offline_pages()
>
> offline_pages()
> lock_memory_hotplug();
> __offline_pages();
> unlock_memory_hotplug();
>
> and implement remove_memory() like this:
> remove_memory()
> lock_memory_hotplug()
> if (!is_memblk_offline()) {
> __offline_pages();
> }
> // cleanup
> unlock_memory_hotplug();
>
> What about this?
I also thought about it once. But a problem remains. Current offilne_pages()
cannot realize the memory has been removed by remove_memory(). So even if
protecting the race by lock_memory_hotplug(), offline_pages() can offline
the removed memory. offline_pages() should have the means to know the memory
was removed. But I don't have good idea.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>>
>> Thanks,
>> Yasuaki Ishimatsu
>>
>>> Thanks,
>>> Yasuaki Ishimatsu
>>>
Thanks
Wen Congyang
> + if (result)
> + return result;
> +
> + list_del(&info->list);
> + kfree(info);
> + }
> +
> kfree(mem_device);
>
> return 0;
> Index: linux-3.5-rc6/include/linux/memory_hotplug.h
> ===
> --- linux-3.5-rc6.orig/include/linux/memory_hotplug.h 2012-07-09
> 18:08:29.955888542 +0900
> +++ linux-3.5-rc6/include/linux/memory_hotplug.h 2012-07-09
> 18:08:43.471719518 +0900
> @@ -233
[PATCH 2/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue. An else statement was
not on the same line as the preceding if statement's
closing brace.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index a3cb559..50be42a 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -826,8 +826,7 @@ int card_power_on(struct rts51x_chip *chip, u8 card)
if ((card == SD_CARD) || (card == XD_CARD)) {
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask | LDO3318_PWR_MASK,
val1 | LDO_SUSPEND);
- }
- else {
+ } else {
#endif
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask, val1);
#ifdef SD_XD_IO_FOLLOW_PWR
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index 4192c3b..a3cb559 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -211,13 +211,12 @@ static void card_cd_debounce(struct rts51x_chip *chip, u8
*need_reset,
release_map |= MS_CARD;
}
} else {
- if (chip->card_status & XD_CD) {
+ if (chip->card_status & XD_CD)
reset_map |= XD_CARD;
- } else if (chip->card_status & SD_CD) {
+ else if (chip->card_status & SD_CD)
reset_map |= SD_CARD;
- } else if (chip->card_status & MS_CD) {
+ else if (chip->card_status & MS_CD)
reset_map |= MS_CARD;
- }
}
if (CHECK_PKG(chip, QFN24) && reset_map) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
staging: rts5139: rts51x_card: coding style fix
This patch-set fixes coding style issues in rts51x_card driver. Issues were found with scripts/checkpatch.pl tool. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
On Tue, 2012-07-17 at 11:08 +0900, Masami Hiramatsu wrote: > > I found that regs_get_register() doesn't honor this either. Thus, > > kprobes in tracing gets this: > > > > # echo 'p:ftrace sys_read+4 s=%sp' > /debug/tracing/kprobe_events > > # echo 1 > /debug/tracing/events/kprobes/enable > > # cat trace > > sshd-1345 [000] d... 489.117168: ftrace: (sys_read+0x4/0x70) > > s=b7e96768 > > sshd-1345 [000] d... 489.117191: ftrace: (sys_read+0x4/0x70) > > s=b7e96768 > > cat-1447 [000] d... 489.117392: ftrace: (sys_read+0x4/0x70) > > s=5a7 > > cat-1447 [001] d... 489.118023: ftrace: (sys_read+0x4/0x70) > > s=b77ad05f > > less-1448 [000] d... 489.118079: ftrace: (sys_read+0x4/0x70) > > s=b7762e06 > > less-1448 [000] d... 489.118117: ftrace: (sys_read+0x4/0x70) > > s=b7764970 > > > > Yes, that is by design, since I made it so. :) > Instead of %sp, kprobe tracer provides $stack special argument > for stack address, because "sp" is not always means the stack > address on every arch. But is that useful? Wouldn't the actual stack pointer be more informative? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] sched: dynamically schedule domain configuration
Add the missing cc list.
On 07/16/2012 05:16 PM, Michael Wang wrote:
> From: Michael Wang
>
> This patch is trying to provide a way for user to dynamically change
> the behaviour of load balance by setting flags of schedule domain.
>
> Currently it's rely on cpu cgroup and only SD_LOAD_BALANCE was
> implemented, usage:
>
> 1. /sys/fs/cgroup/domain/domain.config_level
> the default config_level is 0, which means we currenlty configure
> the sibling domain for all cpus, we can use:
> echo 'number' > /sys/fs/cgroup/domain/domain.config_level
> to change the level.
>
> 2. /sys/fs/cgroup/domain/domain.topology
> this will help to show the SD_LOAD_BALANCE status of all the cpu's
> all domain level, we can use:
> cat /sys/fs/cgroup/domain/domain.topology
>
> 3. /sys/fs/cgroup/domain/domain.SD_LOAD_BALANCE
> this will help us to change the bit SD_LOAD_BALANCE in the flag of
> schedule domain on level 'config_level', we can use:
> echo 1 > /sys/fs/cgroup/domain/domain.SD_LOAD_BALANCE
> to enable this bit, and:
> echo 0 > /sys/fs/cgroup/domain/domain.SD_LOAD_BALANCE
> to disable it.
>
> It may not works well now(may be even not work at all as I can't see any
> changes on my server even after disabled SD_LOAD_BALANCE on all domains),
> but it is interesting and should be liked by some people who desire a
> way to 'kill' the load balance by their own hands if we can implement it.
>
> Comments and questions are very welcomed ;-)
>
> Signed-off-by: Michael Wang
> ---
> include/linux/cgroup_subsys.h |1 +
> kernel/sched/core.c | 143
> +
> 2 files changed, 144 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
> index 0bd390c..25eb842 100644
> --- a/include/linux/cgroup_subsys.h
> +++ b/include/linux/cgroup_subsys.h
> @@ -21,6 +21,7 @@ SUBSYS(debug)
>
> #ifdef CONFIG_CGROUP_SCHED
> SUBSYS(cpu_cgroup)
> +SUBSYS(domain_cgroup)
> #endif
>
> /* */
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3987b9d..544bf78 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -8423,6 +8423,149 @@ struct cgroup_subsys cpu_cgroup_subsys = {
> .early_init = 1,
> };
>
> +static struct cgroup_subsys_state domain_cgroup_css;
> +static struct cgroup_subsys_state *domain_cgroup_create(struct cgroup *cgrp)
> +{
> + if (!cgrp->parent) {
> + /* This is early initialization for the top cgroup */
> + return &domain_cgroup_css;
> + }
> +
> + return ERR_PTR(-EPERM);
> +}
> +
> +static void domain_cgroup_destroy(struct cgroup *cgrp)
> +{
> + return;
> +}
> +
> +static int domain_cgroup_can_attach(struct cgroup *cgrp,
> + struct cgroup_taskset *tset)
> +{
> + return -EINVAL;
> +}
> +
> +static void domain_cgroup_attach(struct cgroup *cgrp,
> + struct cgroup_taskset *tset)
> +{
> + return;
> +}
> +
> +static void domain_cgroup_exit(struct cgroup *cgrp,
> +struct cgroup *old_cgrp,
> +struct task_struct *task)
> +{
> + return;
> +}
> +
> +static int domain_config_level;
> +
> +static int domain_cl_write_u64(struct cgroup *cgrp,
> +struct cftype *cftype,
> +u64 shareval)
> +{
> + domain_config_level = shareval;
> + return 0;
> +}
> +
> +static u64 domain_cl_read_u64(struct cgroup *cgrp, struct cftype *cft)
> +{
> + return (u64)domain_config_level;
> +}
> +
> +static int domain_slb_write_u64(struct cgroup *cgrp,
> + struct cftype *cftype,
> + u64 shareval)
> +{
> + int cpu;
> + struct sched_domain *sd;
> + if (shareval != 0 && shareval != 1)
> + return -EINVAL;
> +
> + mutex_lock(&sched_domains_mutex);
> + for_each_cpu(cpu, cpu_active_mask) {
> + for (sd = cpu_rq(cpu)->sd; sd; sd = sd->parent) {
> + if (sd->level == domain_config_level) {
> + if (shareval)
> + sd->flags |= SD_LOAD_BALANCE;
> + else
> + sd->flags &= ~SD_LOAD_BALANCE;
> + }
> + }
> + }
> + mutex_unlock(&sched_domains_mutex);
> + return 0;
> +}
> +
> +static u64 domain_slb_read_u64(struct cgroup *cgrp, struct cftype *cft)
> +{
> + int cpu, ret = 0;
> + struct sched_domain *sd;
> + mutex_lock(&sched_domains_mutex);
> + for_each_cpu(cpu, cpu_active_mask) {
> + for (sd = cpu_rq(cpu)->sd; sd; sd = sd->parent) {
> + if (sd->level == domain_config_level) {
> + if (sd->flags & SD_LOAD_BALANCE)
> +
[PATCH RESEND] Fix a dead loop in async_synchronize_full()
resend it again with the email client fixed... in case it is needed
This patch tries to fix a dead loop in async_synchronize_full(), which
could be seen when preemption is disabled on a single cpu machine.
void async_synchronize_full(void)
{
do {
async_synchronize_cookie(next_cookie);
} while (!list_empty(&async_running) || !
list_empty(&async_pending));
}
async_synchronize_cookie() calls async_synchronize_cookie_domain() with
&async_running as the default domain to synchronize.
However, there might be some works in the async_pending list from other
domains. On a single cpu system, without preemption, there is no chance
for the other works to finish, so async_synchronize_full() enters a dead
loop.
It seems async_synchronize_full() wants to synchronize all entries in
all running lists(domains), so maybe we could just check the entry_count
to know whether all works are finished.
Currently, async_synchronize_cookie_domain() expects a non-NULL running
list ( if NULL, there would be NULL pointer dereference ), so maybe a
NULL pointer could be used as an indication for the functions to
synchronize all works in all domains.
Reported-by: Paul E. McKenney
Signed-off-by: Li Zhong
Tested-by: Paul E. McKenney
Tested-by: Christian Kujau
---
kernel/async.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/kernel/async.c b/kernel/async.c
index bd0c168..32d8dc9 100644
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -86,6 +86,13 @@ static async_cookie_t __lowest_in_progress(struct list_head
*running)
{
struct async_entry *entry;
+ if (!running) { /* just check the entry count */
+ if (atomic_read(&entry_count))
+ return 0; /* smaller than any cookie */
+ else
+ return next_cookie;
+ }
+
if (!list_empty(running)) {
entry = list_first_entry(running,
struct async_entry, list);
@@ -236,9 +243,7 @@ EXPORT_SYMBOL_GPL(async_schedule_domain);
*/
void async_synchronize_full(void)
{
- do {
- async_synchronize_cookie(next_cookie);
- } while (!list_empty(&async_running) || !list_empty(&async_pending));
+ async_synchronize_cookie_domain(next_cookie, NULL);
}
EXPORT_SYMBOL_GPL(async_synchronize_full);
@@ -258,7 +263,7 @@ EXPORT_SYMBOL_GPL(async_synchronize_full_domain);
/**
* async_synchronize_cookie_domain - synchronize asynchronous function calls
within a certain domain with cookie checkpointing
* @cookie: async_cookie_t to use as checkpoint
- * @running: running list to synchronize on
+ * @running: running list to synchronize on, NULL indicates all lists
*
* This function waits until all asynchronous function calls for the
* synchronization domain specified by the running list @list submitted
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/4] kvm: Create kvm_clear_irq()
On Tue, 2012-07-17 at 03:51 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 16, 2012 at 02:34:03PM -0600, Alex Williamson wrote:
> > This is an alternative to kvm_set_irq(,,,0) which returns the previous
> > assertion state of the interrupt and does nothing if it isn't changed.
> >
> > Signed-off-by: Alex Williamson
> > ---
> >
> > include/linux/kvm_host.h |3 ++
> > virt/kvm/irq_comm.c | 78
> > ++
> > 2 files changed, 81 insertions(+)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index a7661c0..6c168f1 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -219,6 +219,8 @@ struct kvm_kernel_irq_routing_entry {
> > u32 type;
> > int (*set)(struct kvm_kernel_irq_routing_entry *e,
> >struct kvm *kvm, int irq_source_id, int level);
> > + int (*clear)(struct kvm_kernel_irq_routing_entry *e,
> > +struct kvm *kvm, int irq_source_id);
> > union {
> > struct {
> > unsigned irqchip;
> > @@ -629,6 +631,7 @@ void kvm_get_intr_delivery_bitmask(struct kvm_ioapic
> > *ioapic,
> >unsigned long *deliver_bitmask);
> > #endif
> > int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 irq, int level);
> > +int kvm_clear_irq(struct kvm *kvm, int irq_source_id, u32 irq);
> > int kvm_set_msi(struct kvm_kernel_irq_routing_entry *irq_entry, struct kvm
> > *kvm,
> > int irq_source_id, int level);
> > void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin);
> > diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
> > index 5afb431..76e8f22 100644
> > --- a/virt/kvm/irq_comm.c
> > +++ b/virt/kvm/irq_comm.c
> > @@ -68,6 +68,42 @@ static int kvm_set_ioapic_irq(struct
> > kvm_kernel_irq_routing_entry *e,
> > return kvm_ioapic_set_irq(ioapic, e->irqchip.pin, level);
> > }
> >
> > +static inline int kvm_clear_irq_line_state(unsigned long *irq_state,
> > + int irq_source_id)
> > +{
> > + return !!test_and_clear_bit(irq_source_id, irq_state);
> > +}
> > +
> > +static int kvm_clear_pic_irq(struct kvm_kernel_irq_routing_entry *e,
> > +struct kvm *kvm, int irq_source_id)
> > +{
> > +#ifdef CONFIG_X86
> > + struct kvm_pic *pic = pic_irqchip(kvm);
> > + int level = kvm_clear_irq_line_state(&pic->irq_states[e->irqchip.pin],
> > +irq_source_id);
> > + if (level)
> > + kvm_pic_set_irq(pic, e->irqchip.pin,
> > + !!pic->irq_states[e->irqchip.pin]);
> > + return level;
> > +#else
> > + return -1;
> > +#endif
>
> What does this ifdef exclude exactly?
No pic on ia64. Not that it works, but I figured the consistency with
kvm_set_pic_irq would make more sense whenever someone goes through and
cleans out the code. Thanks,
Alex
> > +}
> > +
> > +static int kvm_clear_ioapic_irq(struct kvm_kernel_irq_routing_entry *e,
> > + struct kvm *kvm, int irq_source_id)
> > +{
> > + struct kvm_ioapic *ioapic = kvm->arch.vioapic;
> > + int level;
> > +
> > + level = kvm_clear_irq_line_state(&ioapic->irq_states[e->irqchip.pin],
> > +irq_source_id);
> > + if (level)
> > + kvm_ioapic_set_irq(ioapic, e->irqchip.pin,
> > + !!ioapic->irq_states[e->irqchip.pin]);
> > + return level;
> > +}
> > +
> > inline static bool kvm_is_dm_lowest_prio(struct kvm_lapic_irq *irq)
> > {
> > #ifdef CONFIG_IA64
> > @@ -190,6 +226,45 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id,
> > u32 irq, int level)
> > return ret;
> > }
> >
> > +/*
> > + * Return value:
> > + * < 0 Error
> > + * = 0 Interrupt was not set, did nothing
> > + * > 0 Interrupt was pending, cleared
> > + */
> > +int kvm_clear_irq(struct kvm *kvm, int irq_source_id, u32 irq)
> > +{
> > + struct kvm_kernel_irq_routing_entry *e, irq_set[KVM_NR_IRQCHIPS];
> > + int ret = -EINVAL, i = 0;
> > + struct kvm_irq_routing_table *irq_rt;
> > + struct hlist_node *n;
> > +
> > + /* Not possible to detect if the guest uses the PIC or the
> > +* IOAPIC. So clear the bit in both. The guest will ignore
> > +* writes to the unused one.
> > +*/
> > + rcu_read_lock();
> > + irq_rt = rcu_dereference(kvm->irq_routing);
> > + if (irq < irq_rt->nr_rt_entries)
> > + hlist_for_each_entry(e, n, &irq_rt->map[irq], link)
> > + irq_set[i++] = *e;
> > + rcu_read_unlock();
> > +
> > + while (i--) {
> > + int r = -EINVAL;
> > +
> > + if (irq_set[i].clear)
> > + r = irq_set[i].clear(&irq_set[i], kvm, irq_source_id);
> > +
> > + if (r < 0)
> > + continue;
> > +
> > + ret = r + ((ret < 0) ? 0 : ret);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > void kvm_notif
Re: [PATCH] net-next: make sock diag per-namespace (v2)
On 07/16/2012 06:28 PM, Andrew Vagin wrote: > Before this patch sock_diag works for init_net only and dumps > information about sockets from all namespaces. > > This patch expands sock_diag for all name-spaces. > It creates a netlink kernel socket for each netns and filters > data during dumping. > > v2: filter accoding with netns in all places > remove an unused variable. > > Cc: "David S. Miller" > Cc: Alexey Kuznetsov > Cc: James Morris > Cc: Hideaki YOSHIFUJI > Cc: Patrick McHardy > Cc: Pavel Emelyanov > CC: Eric Dumazet > Cc: linux-kernel@vger.kernel.org > Cc: net...@vger.kernel.org > Signed-off-by: Andrew Vagin Acked-by: Pavel Emelyanov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
