Re: [PATCH] usb: udc: add gadget state kobject uevent
2013/7/18 Felipe Balbi : > On Thu, Jul 18, 2013 at 05:28:19PM +0800, Rong Wang wrote: >> Hi Felipe, >> >> Thanks, I'll test the patch. >> >> But sysfs_notify(>dev.kobj, NULL, "status"), status or state ? >> I notice that DEVICE_ATTR(state, S_IRUGO, usb_gadget_state_show, NULL) > > good eyes, please send a patch which I'll queue on this -rc and Cc: > . ok. i will handle that for rong. and pls consider to merge rong's patch about sending uevent. > > I'll rewrite my patch on top of the patched -rc later. > > -- > balbi -barry -- 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: [trivial PATCH] treewide: Fix printks with 0x%#
At Thu, 25 Jul 2013 11:53:25 -0700,
Joe Perches wrote:
>
>
> Using 0x%# emits 0x0x. Only one is necessary.
>
> Signed-off-by: Joe Perches
Acked-by: Takashi Iwai
thanks,
Takashi
> ---
> arch/parisc/kernel/signal.c | 2 +-
> drivers/clocksource/acpi_pm.c | 4 ++--
> drivers/net/ethernet/sis/sis900.c | 2 +-
> mm/memory-failure.c | 2 +-
> sound/pci/ens1370.c | 2 +-
> sound/pci/via82xx.c | 2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
> index 940188d..35c5bf1 100644
> --- a/arch/parisc/kernel/signal.c
> +++ b/arch/parisc/kernel/signal.c
> @@ -85,7 +85,7 @@ restore_sigcontext(struct sigcontext __user *sc, struct
> pt_regs *regs)
> err |= __copy_from_user(regs->iaoq, sc->sc_iaoq, sizeof(regs->iaoq));
> err |= __copy_from_user(regs->iasq, sc->sc_iasq, sizeof(regs->iasq));
> err |= __get_user(regs->sar, >sc_sar);
> - DBG(2,"restore_sigcontext: iaoq is 0x%#lx / 0x%#lx\n",
> + DBG(2,"restore_sigcontext: iaoq is %#lx / %#lx\n",
> regs->iaoq[0],regs->iaoq[1]);
> DBG(2,"restore_sigcontext: r28 is %ld\n", regs->gr[28]);
> return err;
> diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
> index 6efe4d1..6eab889 100644
> --- a/drivers/clocksource/acpi_pm.c
> +++ b/drivers/clocksource/acpi_pm.c
> @@ -200,14 +200,14 @@ static int __init init_acpi_pm_clocksource(void)
> if ((value2 < value1) && ((value2) < 0xFFF))
> break;
> printk(KERN_INFO "PM-Timer had inconsistent results:"
> -" 0x%#llx, 0x%#llx - aborting.\n",
> +" %#llx, %#llx - aborting.\n",
> value1, value2);
> pmtmr_ioport = 0;
> return -EINVAL;
> }
> if (i == ACPI_PM_READ_CHECKS) {
> printk(KERN_INFO "PM-Timer failed consistency check "
> -" (0x%#llx) - aborting.\n", value1);
> +" (%#llx) - aborting.\n", value1);
> pmtmr_ioport = 0;
> return -ENODEV;
> }
> diff --git a/drivers/net/ethernet/sis/sis900.c
> b/drivers/net/ethernet/sis/sis900.c
> index eb4aea3..6c1e34c 100644
> --- a/drivers/net/ethernet/sis/sis900.c
> +++ b/drivers/net/ethernet/sis/sis900.c
> @@ -1723,7 +1723,7 @@ static irqreturn_t sis900_interrupt(int irq, void
> *dev_instance)
>
> if(netif_msg_intr(sis_priv))
> printk(KERN_DEBUG "%s: exiting interrupt, "
> -"interrupt status = 0x%#8.8x.\n",
> +"interrupt status = %#8.8x\n",
> net_dev->name, sr32(isr));
>
> spin_unlock (_priv->lock);
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 09ae111..29d3f38 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1267,7 +1267,7 @@ void memory_failure_queue(unsigned long pfn, int
> trapno, int flags)
> if (kfifo_put(_cpu->fifo, ))
> schedule_work_on(smp_processor_id(), _cpu->work);
> else
> - pr_err("Memory failure: buffer overflow when queuing memory
> failure at 0x%#lx\n",
> + pr_err("Memory failure: buffer overflow when queuing memory
> failure at %#lx\n",
> pfn);
> spin_unlock_irqrestore(_cpu->lock, proc_flags);
> put_cpu_var(memory_failure_cpu);
> diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c
> index ca8929b..61262f3 100644
> --- a/sound/pci/ens1370.c
> +++ b/sound/pci/ens1370.c
> @@ -1842,7 +1842,7 @@ static int snd_ensoniq_create_gameport(struct ensoniq
> *ensoniq, int dev)
>
> default:
> if (!request_region(io_port, 8, "ens137x: gameport")) {
> - printk(KERN_WARNING "ens137x: gameport io port 0x%#x in
> use\n",
> + printk(KERN_WARNING "ens137x: gameport io port %#x in
> use\n",
> io_port);
> return -EBUSY;
> }
> diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c
> index 3c511d0..5ae6f04 100644
> --- a/sound/pci/via82xx.c
> +++ b/sound/pci/via82xx.c
> @@ -1940,7 +1940,7 @@ static int snd_via686_create_gameport(struct via82xx
> *chip, unsigned char *legac
>
> r = request_region(JOYSTICK_ADDR, 8, "VIA686 gameport");
> if (!r) {
> - printk(KERN_WARNING "via82xx: cannot reserve joystick port
> 0x%#x\n",
> + printk(KERN_WARNING "via82xx: cannot reserve joystick port
> %#x\n",
> JOYSTICK_ADDR);
> return -EBUSY;
> }
>
>
>
--
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
Re: [V2 2/2] powerpc/512x: add LocalPlus Bus FIFO device driver
Thanks, Gerhard. I'll improve the code and return with the third version. Best regards, Alexander. -- 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 Jul 25 (ahci_imx.c)
On Fri, Jul 26, 2013 at 04:58:14AM +, Zhu Richard-R65037 wrote: > Hi Shawn: > yes, it is. > > BTW, Should I re-send the AHCI_IMX patch-set or send out one stand-alone > patch to fix this issue? > I think an incremental fixing patch is good. Shawn -- 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 RFC PATCH 5/5] cpuidle/ppc: Add longnap state to the idle states on powernv
This patch hooks into the existing broadcast framework with the support that
this
patchset introduces for ppc, and the cpuidle driver backend
for powernv(posted out recently by Deepthi Dharwar) to add sleep state as
one of the deep idle states, in which the decrementer is switched off.
However in this patch, we only emulate sleep by going into a state which does
a nap with the decrementer interrupts disabled, termed as longnap. This enables
focus on the timer broadcast framework for ppc in this series of patches ,
which is required as a first step to enable sleep on ppc.
Signed-off-by: Preeti U Murthy
---
arch/powerpc/platforms/powernv/processor_idle.c | 48 +++
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/processor_idle.c
b/arch/powerpc/platforms/powernv/processor_idle.c
index f43ad91a..9aca502 100644
--- a/arch/powerpc/platforms/powernv/processor_idle.c
+++ b/arch/powerpc/platforms/powernv/processor_idle.c
@@ -9,16 +9,18 @@
#include
#include
#include
+#include
#include
#include
+#include
struct cpuidle_driver powernv_idle_driver = {
.name = "powernv_idle",
.owner =THIS_MODULE,
};
-#define MAX_IDLE_STATE_COUNT 2
+#define MAX_IDLE_STATE_COUNT 3
static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
static struct cpuidle_device __percpu *powernv_cpuidle_devices;
@@ -54,6 +56,43 @@ static int nap_loop(struct cpuidle_device *dev,
return index;
}
+/* Emulate sleep, with long nap.
+ * During sleep, the core does not receive decrementer interrupts.
+ * Emulate sleep using long nap with decrementers interrupts disabled.
+ * This is an initial prototype to test the timer offload framework for ppc.
+ * We will eventually introduce the sleep state once the timer offload
framework
+ * for ppc is stable.
+ */
+static int longnap_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int cpu = dev->cpu;
+
+ unsigned long lpcr = mfspr(SPRN_LPCR);
+
+ lpcr &= ~(LPCR_MER | LPCR_PECE); /* lpcr[mer] must be 0 */
+
+ /* exit powersave upon external interrupt, but not decrementer
+* interrupt, Emulate sleep.
+*/
+ lpcr |= LPCR_PECE0;
+
+ if (cpu != bc_cpu) {
+ mtspr(SPRN_LPCR, lpcr);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, );
+ power7_nap();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, );
+ } else {
+ /* Wakeup on a decrementer interrupt, Do a nap */
+ lpcr |= LPCR_PECE1;
+ mtspr(SPRN_LPCR, lpcr);
+ power7_nap();
+ }
+
+ return index;
+}
+
/*
* States for dedicated partition case.
*/
@@ -72,6 +111,13 @@ static struct cpuidle_state
powernv_states[MAX_IDLE_STATE_COUNT] = {
.exit_latency = 10,
.target_residency = 100,
.enter = _loop },
+{ /* LongNap */
+ .name = "LongNap",
+ .desc = "LongNap",
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 10,
+ .target_residency = 100,
+ .enter = _loop },
};
static int powernv_cpuidle_add_cpu_notifier(struct notifier_block *n,
--
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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Thu, Jul 25, 2013 at 11:44:50PM +, Daniel Phillips wrote: > Hi Willy, > > I understand completely. I don't blame you. Filter the thread. Done. So because people speak loudly at night below my window in summer, I have to close the window and install a fan to get some air ? And all the neighbours have to do the same ? Sorry, there are places for this I'd rather politely ask them to go to these places. And anyway it's much easier for me to write rules to block addresses than subjects, so if I am bored enough to write a rule it will target the participants. Keep your discussion on LKML if you want it to be public, it's even on the subject and nobody will care because nobody has it in his main mailbox anymore. But please remove the other people that were left CCed and who don't participate to the thread, as well as the ksummit and stable lists that are for completely different purposes. Thanks, Willy -- 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 RFC PATCH 3/5] cpuidle/ppc: Add timer offload framework to support deep idle states
On ppc, in deep idle states, the local clock event device of CPUs gets
switched off. On PowerPC, the local clock event device is called the
decrementer. Make use of the broadcast framework to issue interrupts to
cpus in deep idle states on their timer events, except that on ppc, we
do not have an external device such as HPET, but we use the decrementer
of one of the CPUs itself as the broadcast device.
Instantiate two different clock event devices, one representing the
decrementer and another representing the broadcast device for each cpu.
The cpu which registers its broadcast device will be responsible for
performing the function of issuing timer interrupts to CPUs in deep idle
states, and is referred to as the broadcast cpu in the changelogs of this
patchset for convenience. Such a CPU is not allowed to enter deep idle
states, where the decrementer is switched off.
For now, only the boot cpu's broadcast device gets registered as a clock event
device along with the decrementer. Hence this is the broadcast cpu.
On the broadcast cpu, on each timer interrupt, apart from the regular local
timer event handler the broadcast handler is also called. We avoid the overhead
of programming the decrementer specifically for a broadcast event. The reason
is for
performance and scalability reasons. Say cpuX goes to deep idle state. It
has to ask the broadcast CPU to reprogram its(broadcast CPU's) decrementer for
the next local timer event of cpuX. cpuX can do so only by sending an IPI to the
broadcast CPU. With many more cpus going to deep idle, this model of sending
IPIs each time will result in performance bottleneck and may not scale well.
Apart from this there is no change in the way broadcast is handled today. On
a broadcast ipi the event handler for a timer interrupt is called on the cpu
in deep idle state to handle the local events.
The current design and implementation of the timer offload framework supports
the ONESHOT tick mode but not the PERIODIC mode.
Signed-off-by: Preeti U. Murthy
---
arch/powerpc/include/asm/time.h|3 +
arch/powerpc/kernel/smp.c |4 +-
arch/powerpc/kernel/time.c | 81
arch/powerpc/platforms/powernv/Kconfig |1
4 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index c1f2676..936be0d 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -24,14 +24,17 @@ extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
extern struct clock_event_device decrementer_clockevent;
+extern struct clock_event_device broadcast_clockevent;
struct rtc_time;
extern void to_tm(int tim, struct rtc_time * tm);
extern void GregorianDay(struct rtc_time *tm);
+extern void decrementer_timer_interrupt(void);
extern void generic_calibrate_decr(void);
extern void set_dec_cpu6(unsigned int val);
+extern int bc_cpu;
/* Some sane defaults: 125 MHz timebase, 1GHz processor */
extern unsigned long ppc_proc_freq;
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 6a68ca4..d3b7014 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -114,7 +114,7 @@ int smp_generic_kick_cpu(int nr)
static irqreturn_t timer_action(int irq, void *data)
{
- timer_interrupt();
+ decrementer_timer_interrupt();
return IRQ_HANDLED;
}
@@ -223,7 +223,7 @@ irqreturn_t smp_ipi_demux(void)
#ifdef __BIG_ENDIAN
if (all & (1 << (24 - 8 * PPC_MSG_TIMER)))
- timer_interrupt();
+ decrementer_timer_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 65ab9e9..7e858e1 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -97,8 +98,11 @@ static struct clocksource clocksource_timebase = {
static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev);
+static int broadcast_set_next_event(unsigned long evt,
+ struct clock_event_device *dev);
static void decrementer_set_mode(enum clock_event_mode mode,
struct clock_event_device *dev);
+static void decrementer_timer_broadcast(const struct cpumask *mask);
struct clock_event_device decrementer_clockevent = {
.name = "decrementer",
@@ -106,13 +110,26 @@ struct clock_event_device decrementer_clockevent = {
.irq= 0,
.set_next_event = decrementer_set_next_event,
.set_mode = decrementer_set_mode,
-
[Resend RFC PATCH 2/5] powerpc: Implement broadcast timer interrupt as an IPI message
From: Srivatsa S. Bhat
For scalability and performance reasons, we want the broadcast timer
interrupts to be handled as efficiently as possible. Fixed IPI messages
are one of the most efficient mechanisms available - they are faster
than the smp_call_function mechanism because the IPI handlers are fixed
and hence they don't involve costly operations such as adding IPI handlers
to the target CPU's function queue, acquiring locks for synchronization etc.
Luckily we have an unused IPI message slot, so use that to implement
broadcast timer interrupts efficiently.
Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Preeti U Murthy
---
arch/powerpc/include/asm/smp.h |3 ++-
arch/powerpc/kernel/smp.c | 19 +++
arch/powerpc/platforms/cell/interrupt.c |2 +-
arch/powerpc/platforms/ps3/smp.c|2 +-
4 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 51bf017..d877b69 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -117,7 +117,7 @@ extern int cpu_to_core_id(int cpu);
*
* Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
* in /proc/interrupts will be wrong!!! --Troy */
-#define PPC_MSG_UNUSED 0
+#define PPC_MSG_TIMER 0
#define PPC_MSG_RESCHEDULE 1
#define PPC_MSG_CALL_FUNC_SINGLE 2
#define PPC_MSG_DEBUGGER_BREAK 3
@@ -190,6 +190,7 @@ extern struct smp_ops_t *smp_ops;
extern void arch_send_call_function_single_ipi(int cpu);
extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
+extern void arch_send_tick_broadcast(const struct cpumask *mask);
/* Definitions relative to the secondary CPU spin loop
* and entry point. Not all of them exist on both 32 and
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index bc41e9f..6a68ca4 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -111,9 +112,9 @@ int smp_generic_kick_cpu(int nr)
}
#endif /* CONFIG_PPC64 */
-static irqreturn_t unused_action(int irq, void *data)
+static irqreturn_t timer_action(int irq, void *data)
{
- /* This slot is unused and hence available for use, if needed */
+ timer_interrupt();
return IRQ_HANDLED;
}
@@ -144,14 +145,14 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
}
static irq_handler_t smp_ipi_action[] = {
- [PPC_MSG_UNUSED] = unused_action, /* Slot available for future use */
+ [PPC_MSG_TIMER] = timer_action,
[PPC_MSG_RESCHEDULE] = reschedule_action,
[PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
};
const char *smp_ipi_name[] = {
- [PPC_MSG_UNUSED] = "ipi unused",
+ [PPC_MSG_TIMER] = "ipi timer",
[PPC_MSG_RESCHEDULE] = "ipi reschedule",
[PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
[PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
@@ -221,6 +222,8 @@ irqreturn_t smp_ipi_demux(void)
all = xchg(>messages, 0);
#ifdef __BIG_ENDIAN
+ if (all & (1 << (24 - 8 * PPC_MSG_TIMER)))
+ timer_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
@@ -266,6 +269,14 @@ void arch_send_call_function_ipi_mask(const struct cpumask
*mask)
do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
}
+void arch_send_tick_broadcast(const struct cpumask *mask)
+{
+ unsigned int cpu;
+
+ for_each_cpu(cpu, mask)
+ do_message_pass(cpu, PPC_MSG_TIMER);
+}
+
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
void smp_send_debugger_break(void)
{
diff --git a/arch/powerpc/platforms/cell/interrupt.c
b/arch/powerpc/platforms/cell/interrupt.c
index 28166e4..1359113 100644
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -213,7 +213,7 @@ static void iic_request_ipi(int msg)
void iic_request_IPIs(void)
{
- iic_request_ipi(PPC_MSG_UNUSED);
+ iic_request_ipi(PPC_MSG_TIMER);
iic_request_ipi(PPC_MSG_RESCHEDULE);
iic_request_ipi(PPC_MSG_CALL_FUNC_SINGLE);
iic_request_ipi(PPC_MSG_DEBUGGER_BREAK);
diff --git a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
index 488f069..5cb742a 100644
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -74,7 +74,7 @@ static int __init ps3_smp_probe(void)
* to index needs to be setup.
*/
- BUILD_BUG_ON(PPC_MSG_UNUSED != 0);
+ BUILD_BUG_ON(PPC_MSG_TIMER!= 0);
BUILD_BUG_ON(PPC_MSG_RESCHEDULE != 1);
[Resend RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states
On PowerPC, when CPUs enter deep idle states, their local timers are switched off. The responsibility of waking them up at their next timer event, needs to be handed over to an external device. On PowerPC, we do not have an external device equivalent to HPET, which is currently done on architectures like x86. Instead we assign the local timer of one of the CPUs to do this job. This patchset is an attempt to make use of the existing timer broadcast framework in the kernel to meet the above requirement, except that the tick broadcast device is the local timer of the boot CPU. This patch series is ported ontop of 3.11-rc1 + the cpuidle driver backend for powernv posted by Deepthi Dharwar recently. The current design and implementation supports the ONESHOT tick mode. It does not yet support the PERIODIC tick mode. This patch is tested with NOHZ_FULL off. Patch[1/5], Patch[2/5]: optimize the broadcast mechanism on ppc. Patch[3/5]: Introduces the core of the timer offload framework on powerpc. Patch[4/5]: The cpu doing the broadcast should not go into tickless idle. Patch[5/5]: Add a deep idle state to the cpuidle state table on powernv. Patch[5/5] is the patch that ultimately makes use of the timer offload framework that the patches Patch[1/5] to Patch[4/5] build. This patch series is being resent to clarify certain ambiguity in the patch descriptions from the previous post. Discussion around this: https://lkml.org/lkml/2013/7/25/754 --- Preeti U Murthy (3): cpuidle/ppc: Add timer offload framework to support deep idle states cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints cpuidle/ppc: Add longnap state to the idle states on powernv Srivatsa S. Bhat (2): powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC) powerpc: Implement broadcast timer interrupt as an IPI message arch/powerpc/include/asm/smp.h |3 + arch/powerpc/include/asm/time.h |3 + arch/powerpc/kernel/smp.c | 23 -- arch/powerpc/kernel/time.c | 86 +++ arch/powerpc/platforms/cell/interrupt.c |2 - arch/powerpc/platforms/powernv/Kconfig |1 arch/powerpc/platforms/powernv/processor_idle.c | 48 + arch/powerpc/platforms/ps3/smp.c|2 - kernel/time/tick-sched.c|7 ++ 9 files changed, 163 insertions(+), 12 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/
[Resend RFC PATCH 1/5] powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC)
From: Srivatsa S. Bhat
The IPI handlers for both PPC_MSG_CALL_FUNC and PPC_MSG_CALL_FUNC_SINGLE
map to a common implementation - generic_smp_call_function_single_interrupt().
So, we can consolidate them and save one of the IPI message slots, (which are
precious, since only 4 of those slots are available).
So, implement the functionality of PPC_MSG_CALL_FUNC using
PPC_MSG_CALL_FUNC_SINGLE itself and release its IPI message slot, so that it
can be used for something else in the future, if desired.
Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Preeti U Murthy
---
arch/powerpc/include/asm/smp.h |2 +-
arch/powerpc/kernel/smp.c | 12 +---
arch/powerpc/platforms/cell/interrupt.c |2 +-
arch/powerpc/platforms/ps3/smp.c|2 +-
4 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index ffbaabe..51bf017 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -117,7 +117,7 @@ extern int cpu_to_core_id(int cpu);
*
* Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
* in /proc/interrupts will be wrong!!! --Troy */
-#define PPC_MSG_CALL_FUNCTION 0
+#define PPC_MSG_UNUSED 0
#define PPC_MSG_RESCHEDULE 1
#define PPC_MSG_CALL_FUNC_SINGLE 2
#define PPC_MSG_DEBUGGER_BREAK 3
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..bc41e9f 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -111,9 +111,9 @@ int smp_generic_kick_cpu(int nr)
}
#endif /* CONFIG_PPC64 */
-static irqreturn_t call_function_action(int irq, void *data)
+static irqreturn_t unused_action(int irq, void *data)
{
- generic_smp_call_function_interrupt();
+ /* This slot is unused and hence available for use, if needed */
return IRQ_HANDLED;
}
@@ -144,14 +144,14 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
}
static irq_handler_t smp_ipi_action[] = {
- [PPC_MSG_CALL_FUNCTION] = call_function_action,
+ [PPC_MSG_UNUSED] = unused_action, /* Slot available for future use */
[PPC_MSG_RESCHEDULE] = reschedule_action,
[PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
};
const char *smp_ipi_name[] = {
- [PPC_MSG_CALL_FUNCTION] = "ipi call function",
+ [PPC_MSG_UNUSED] = "ipi unused",
[PPC_MSG_RESCHEDULE] = "ipi reschedule",
[PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
[PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
@@ -221,8 +221,6 @@ irqreturn_t smp_ipi_demux(void)
all = xchg(>messages, 0);
#ifdef __BIG_ENDIAN
- if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNCTION)))
- generic_smp_call_function_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
@@ -265,7 +263,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask
*mask)
unsigned int cpu;
for_each_cpu(cpu, mask)
- do_message_pass(cpu, PPC_MSG_CALL_FUNCTION);
+ do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
}
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
diff --git a/arch/powerpc/platforms/cell/interrupt.c
b/arch/powerpc/platforms/cell/interrupt.c
index 2d42f3b..28166e4 100644
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -213,7 +213,7 @@ static void iic_request_ipi(int msg)
void iic_request_IPIs(void)
{
- iic_request_ipi(PPC_MSG_CALL_FUNCTION);
+ iic_request_ipi(PPC_MSG_UNUSED);
iic_request_ipi(PPC_MSG_RESCHEDULE);
iic_request_ipi(PPC_MSG_CALL_FUNC_SINGLE);
iic_request_ipi(PPC_MSG_DEBUGGER_BREAK);
diff --git a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
index 4b35166..488f069 100644
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -74,7 +74,7 @@ static int __init ps3_smp_probe(void)
* to index needs to be setup.
*/
- BUILD_BUG_ON(PPC_MSG_CALL_FUNCTION!= 0);
+ BUILD_BUG_ON(PPC_MSG_UNUSED != 0);
BUILD_BUG_ON(PPC_MSG_RESCHEDULE != 1);
BUILD_BUG_ON(PPC_MSG_CALL_FUNC_SINGLE != 2);
BUILD_BUG_ON(PPC_MSG_DEBUGGER_BREAK != 3);
--
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 Jul 25 (ahci_imx.c)
Hi Shawn: yes, it is. BTW, Should I re-send the AHCI_IMX patch-set or send out one stand-alone patch to fix this issue? Hi Tejun: What's your opinion? Best Regards Richard Zhu -Original Message- From: Shawn Guo [mailto:shawn@linaro.org] Sent: Friday, July 26, 2013 12:04 PM To: Zhu Richard-R65037 Cc: Randy Dunlap; Stephen Rothwell; linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: linux-next: Tree for Jul 25 (ahci_imx.c) On Fri, Jul 26, 2013 at 03:46:42AM +, Zhu Richard-R65037 wrote: > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Friday, July 26, 2013 2:32 AM > To: Stephen Rothwell > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org; Zhu Richard-R65037 > Subject: Re: linux-next: Tree for Jul 25 (ahci_imx.c) > > On 07/24/13 22:12, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20130724: > > > > on i386: > > # CONFIG_MFD_SYSCON is not set > > > when ahci_imx.c is built as a loadable module: > > ERROR: "syscon_regmap_lookup_by_compatible" [drivers/ata/ahci_imx.ko] > undefined! > > or when it is builtin: > > ahci_imx.c:(.text+0x182e54): undefined reference to > `syscon_regmap_lookup_by_compatible' > We should have it depend on MFD_SYSCON. Shawn -- 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 3/3] blackfin: pinctrl-adi2: Add pin control device groups and function data.
Hi Linus,
On Tue, Jul 16, 2013 at 6:55 PM, Sonic Zhang wrote:
> From: Sonic Zhang
>
> Select PINCTRL_ADI2 for bf54x and bf60x by default.
>
> Signed-off-by: Sonic Zhang
> ---
> arch/blackfin/Kconfig | 7 +
> arch/blackfin/include/asm/portmux.h | 14 +-
> arch/blackfin/mach-bf548/include/mach/portmux.h | 595
> +++-
> arch/blackfin/mach-bf609/include/mach/portmux.h | 477 ++-
> 4 files changed, 1087 insertions(+), 6 deletions(-)
>
> diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
> index 9307e7a..6a3c490 100644
> --- a/arch/blackfin/Kconfig
> +++ b/arch/blackfin/Kconfig
> @@ -325,6 +325,13 @@ config GPIO_ADI
> def_bool y
> depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561)
>
> +config PINCTRL_ADI2
> + def_bool y
> + depends on (BF54x || BF60x)
> + select PINCTRL
> + select PINMUX
> + select IRQ_DOMAIN
> +
> config MEM_MT48LC64M4A2FB_7E
> bool
> depends on (BFIN533_STAMP)
> diff --git a/arch/blackfin/include/asm/portmux.h
> b/arch/blackfin/include/asm/portmux.h
> index 9b1e2c3..6b3e71c 100644
> --- a/arch/blackfin/include/asm/portmux.h
> +++ b/arch/blackfin/include/asm/portmux.h
> @@ -17,14 +17,24 @@
> #define P_MAYSHARE 0x2000
> #define P_DONTCARE 0x1000
>
> -
> +#ifdef CONFIG_PINCTRL
> +#define peripheral_request(per, label) 0
> +#define peripheral_free(per)
> +#define peripheral_request_list(per, label) \
> + (pdev ? (IS_ERR(devm_pinctrl_get_select_default(>dev)) \
> + ? -EINVAL : 0) : 0);
> +#define peripheral_free_list(per)
> +#else
> int peripheral_request(unsigned short per, const char *label);
> void peripheral_free(unsigned short per);
> int peripheral_request_list(const unsigned short per[], const char *label);
> void peripheral_free_list(const unsigned short per[]);
> +#endif
>
> -#include
> +#include
> +#include
> #include
> +#include
>
> #ifndef P_SPORT2_TFS
> #define P_SPORT2_TFS P_UNDEF
> diff --git a/arch/blackfin/mach-bf548/include/mach/portmux.h
> b/arch/blackfin/mach-bf548/include/mach/portmux.h
> index e222462..9fab923 100644
> --- a/arch/blackfin/mach-bf548/include/mach/portmux.h
> +++ b/arch/blackfin/mach-bf548/include/mach/portmux.h
> @@ -7,8 +7,6 @@
> #ifndef _MACH_PORTMUX_H_
> #define _MACH_PORTMUX_H_
>
> -#define MAX_RESOURCES MAX_BLACKFIN_GPIOS
> -
> #define P_SPORT2_TFS (P_DEFINED | P_IDENT(GPIO_PA0) | P_FUNCT(0))
> #define P_SPORT2_DTSEC (P_DEFINED | P_IDENT(GPIO_PA1) | P_FUNCT(0))
> #define P_SPORT2_DTPRI (P_DEFINED | P_IDENT(GPIO_PA2) | P_FUNCT(0))
> @@ -317,4 +315,597 @@
> #define P_NAND_CLE (P_DONTCARE)
> #define P_NAND_ALE (P_DONTCARE)
>
> +#ifdef CONFIG_PINCTRL
> +
> +#include
> +#include
> +#include
> +
> +#define gpio_pint_regs bfin_pint_regs
> +#define adi_internal_set_wake bfin_internal_set_wake
> +
> +static const struct pinctrl_pin_desc adi_pads[] = {
> + PINCTRL_PIN(0, "PA0"),
> + PINCTRL_PIN(1, "PA1"),
> + PINCTRL_PIN(2, "PA2"),
> + PINCTRL_PIN(3, "PG3"),
> + PINCTRL_PIN(4, "PA4"),
> + PINCTRL_PIN(5, "PA5"),
> + PINCTRL_PIN(6, "PA6"),
> + PINCTRL_PIN(7, "PA7"),
> + PINCTRL_PIN(8, "PA8"),
> + PINCTRL_PIN(9, "PA9"),
> + PINCTRL_PIN(10, "PA10"),
> + PINCTRL_PIN(11, "PA11"),
> + PINCTRL_PIN(12, "PA12"),
> + PINCTRL_PIN(13, "PA13"),
> + PINCTRL_PIN(14, "PA14"),
> + PINCTRL_PIN(15, "PA15"),
> + PINCTRL_PIN(16, "PB0"),
> + PINCTRL_PIN(17, "PB1"),
> + PINCTRL_PIN(18, "PB2"),
> + PINCTRL_PIN(19, "PB3"),
> + PINCTRL_PIN(20, "PB4"),
> + PINCTRL_PIN(21, "PB5"),
> + PINCTRL_PIN(22, "PB6"),
> + PINCTRL_PIN(23, "PB7"),
> + PINCTRL_PIN(24, "PB8"),
> + PINCTRL_PIN(25, "PB9"),
> + PINCTRL_PIN(26, "PB10"),
> + PINCTRL_PIN(27, "PB11"),
> + PINCTRL_PIN(28, "PB12"),
> + PINCTRL_PIN(29, "PB13"),
> + PINCTRL_PIN(30, "PB14"),
> + PINCTRL_PIN(32, "PC0"),
> + PINCTRL_PIN(33, "PC1"),
> + PINCTRL_PIN(34, "PC2"),
> + PINCTRL_PIN(35, "PC3"),
> + PINCTRL_PIN(36, "PC4"),
> + PINCTRL_PIN(37, "PC5"),
> + PINCTRL_PIN(38, "PC6"),
> + PINCTRL_PIN(39, "PC7"),
> + PINCTRL_PIN(40, "PC8"),
> + PINCTRL_PIN(41, "PC9"),
> + PINCTRL_PIN(42, "PC10"),
> + PINCTRL_PIN(43, "PC11"),
> + PINCTRL_PIN(44, "PC12"),
> + PINCTRL_PIN(45, "PC13"),
> + PINCTRL_PIN(48, "PD0"),
> + PINCTRL_PIN(49, "PD1"),
> + PINCTRL_PIN(50, "PD2"),
> + PINCTRL_PIN(51, "PD3"),
> + PINCTRL_PIN(52, "PD4"),
> + PINCTRL_PIN(53, "PD5"),
> + PINCTRL_PIN(54, "PD6"),
> + PINCTRL_PIN(55, "PD7"),
> + PINCTRL_PIN(56, "PD8"),
> + PINCTRL_PIN(57, "PD9"),
> + PINCTRL_PIN(58, "PD10"),
> + PINCTRL_PIN(59, "PD11"),
> + PINCTRL_PIN(60, "PD12"),
> + PINCTRL_PIN(61, "PD13"),
> +
Re: [PATCH 2/3] blackfin: gpio: Remove none gpio lib code.
Hi Linus,
On Tue, Jul 16, 2013 at 6:55 PM, Sonic Zhang wrote:
> From: Sonic Zhang
>
> - Remove non gpio lib code from blackfin architecture.
> - Limit the lagecy blackfin gpio driver to bf5xx processors only.
> - Remove unused definition of the pint power functions.
>
> Signed-off-by: Sonic Zhang
> ---
> arch/blackfin/Kconfig| 7 ++
> arch/blackfin/include/asm/gpio.h | 157
> +--
> 2 files changed, 27 insertions(+), 137 deletions(-)
>
> diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
> index 3b6abc5..9307e7a 100644
> --- a/arch/blackfin/Kconfig
> +++ b/arch/blackfin/Kconfig
> @@ -53,6 +53,9 @@ config GENERIC_BUG
> config ZONE_DMA
> def_bool y
>
> +config GENERIC_GPIO
> + def_bool y
> +
> config FORCE_MAX_ZONEORDER
> int
> default "14"
> @@ -318,6 +321,10 @@ config BF53x
> depends on (BF531 || BF532 || BF533 || BF534 || BF536 || BF537)
> default y
>
> +config GPIO_ADI
> + def_bool y
> + depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561)
> +
> config MEM_MT48LC64M4A2FB_7E
> bool
> depends on (BFIN533_STAMP)
> diff --git a/arch/blackfin/include/asm/gpio.h
> b/arch/blackfin/include/asm/gpio.h
> index 98d0133..99d338c 100644
> --- a/arch/blackfin/include/asm/gpio.h
> +++ b/arch/blackfin/include/asm/gpio.h
> @@ -25,8 +25,12 @@
>
> #ifndef __ASSEMBLY__
>
> +#ifndef CONFIG_PINCTRL
> +
> #include
> -#include
> +#include
> +#include
> +#include
>
> /***
> *
> @@ -45,7 +49,6 @@
> * MODIFICATION HISTORY :
> **/
>
> -#if !BFIN_GPIO_PINT
> void set_gpio_dir(unsigned, unsigned short);
> void set_gpio_inen(unsigned, unsigned short);
> void set_gpio_polar(unsigned, unsigned short);
> @@ -115,7 +118,6 @@ struct gpio_port_t {
> unsigned short dummy16;
> unsigned short inen;
> };
> -#endif
>
> #ifdef BFIN_SPECIAL_GPIO_BANKS
> void bfin_special_gpio_free(unsigned gpio);
> @@ -127,25 +129,21 @@ void bfin_special_gpio_pm_hibernate_suspend(void);
> #endif
>
> #ifdef CONFIG_PM
> -int bfin_pm_standby_ctrl(unsigned ctrl);
> +void bfin_gpio_pm_hibernate_restore(void);
> +void bfin_gpio_pm_hibernate_suspend(void);
> +int bfin_gpio_pm_wakeup_ctrl(unsigned gpio, unsigned ctrl);
> +int bfin_gpio_pm_standby_ctrl(unsigned ctrl);
>
> static inline int bfin_pm_standby_setup(void)
> {
> - return bfin_pm_standby_ctrl(1);
> + return bfin_gpio_pm_standby_ctrl(1);
> }
>
> static inline void bfin_pm_standby_restore(void)
> {
> - bfin_pm_standby_ctrl(0);
> + bfin_gpio_pm_standby_ctrl(0);
> }
>
> -void bfin_gpio_pm_hibernate_restore(void);
> -void bfin_gpio_pm_hibernate_suspend(void);
> -void bfin_pint_suspend(void);
> -void bfin_pint_resume(void);
> -
> -# if !BFIN_GPIO_PINT
> -int gpio_pm_wakeup_ctrl(unsigned gpio, unsigned ctrl);
>
> struct gpio_port_s {
> unsigned short data;
> @@ -161,7 +159,6 @@ struct gpio_port_s {
> unsigned short reserved;
> unsigned short mux;
> };
> -# endif
> #endif /*CONFIG_PM*/
>
> /***
> @@ -178,36 +175,29 @@ struct gpio_port_s {
> *
> * MODIFICATION HISTORY :
> **/
> -
> -int bfin_gpio_request(unsigned gpio, const char *label);
> -void bfin_gpio_free(unsigned gpio);
> int bfin_gpio_irq_request(unsigned gpio, const char *label);
> void bfin_gpio_irq_free(unsigned gpio);
> -int bfin_gpio_direction_input(unsigned gpio);
> -int bfin_gpio_direction_output(unsigned gpio, int value);
> -int bfin_gpio_get_value(unsigned gpio);
> -void bfin_gpio_set_value(unsigned gpio, int value);
> +void bfin_gpio_irq_prepare(unsigned gpio);
> +
> +static inline int irq_to_gpio(unsigned irq)
> +{
> + return irq - GPIO_IRQ_BASE;
> +}
> +#endif /* CONFIG_PINCTRL */
>
> #include
> #include
>
> -#ifdef CONFIG_GPIOLIB
> #include /* cansleep wrappers */
>
> static inline int gpio_get_value(unsigned int gpio)
> {
> - if (gpio < MAX_BLACKFIN_GPIOS)
> - return bfin_gpio_get_value(gpio);
> - else
> - return __gpio_get_value(gpio);
> + return __gpio_get_value(gpio);
> }
>
> static inline void gpio_set_value(unsigned int gpio, int value)
> {
> - if (gpio < MAX_BLACKFIN_GPIOS)
> - bfin_gpio_set_value(gpio, value);
> - else
> - __gpio_set_value(gpio, value);
> + __gpio_set_value(gpio, value);
> }
>
> static inline int gpio_cansleep(unsigned int gpio)
> @@ -219,113 +209,6 @@ static inline int gpio_to_irq(unsigned gpio)
> {
> return __gpio_to_irq(gpio);
> }
> -
> -#else /* !CONFIG_GPIOLIB */
> -
> -static inline int gpio_request(unsigned gpio, const char *label)
> -{
> - return
Re: [PATCH 1/3] pinctrl: ADI PIN control driver for the GPIO controller on bf54x and bf60x.
Hi Linus,
On Tue, Jul 16, 2013 at 6:55 PM, Sonic Zhang wrote:
> From: Sonic Zhang
>
> The new ADI GPIO2 controller was introduced since the BF548 and BF60x
> processors. It differs a lot from the old one on BF5xx processors. So,
> create a pinctrl driver under pinctrl framework.
>
> - Define gpio ports and gpio interrupt controllers as individual platform
> devices.
> - Register a pinctrl driver for the whole GPIO ports and GPIO interrupt
> devices.
> - Probe pint devices before port devices. Put device instances into
> respective gpio and pint lists.
> - Define peripheral, irq and gpio reservation bit masks for each gpio
> port as runtime resources.
> - Save and restore gpio port and pint status MMRs in syscore PM functions.
> - Add peripheral device groups and function data into machine portmux.h.
> - Handle peripheral and gpio requests in pinctrl operation functions.
> - Demux gpio IRQs via the irq_domain created by each GPIO port.
>
> Signed-off-by: Sonic Zhang
> ---
> drivers/pinctrl/Makefile |1 +
> drivers/pinctrl/pinctrl-adi2.c | 1545
>
> include/linux/platform_data/pinctrl-adi2.h | 38 +
> 3 files changed, 1584 insertions(+)
> create mode 100644 drivers/pinctrl/pinctrl-adi2.c
> create mode 100644 include/linux/platform_data/pinctrl-adi2.h
>
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index d64563bf..c685958 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_PINCTRL_AB8500) += pinctrl-ab8500.o
> obj-$(CONFIG_PINCTRL_AB8540) += pinctrl-ab8540.o
> obj-$(CONFIG_PINCTRL_AB9540) += pinctrl-ab9540.o
> obj-$(CONFIG_PINCTRL_AB8505) += pinctrl-ab8505.o
> +obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o
> obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
> obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
> obj-$(CONFIG_PINCTRL_BAYTRAIL) += pinctrl-baytrail.o
> diff --git a/drivers/pinctrl/pinctrl-adi2.c b/drivers/pinctrl/pinctrl-adi2.c
> new file mode 100644
> index 000..222a74c
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-adi2.c
> @@ -0,0 +1,1545 @@
> +/*
> + * Pinctrl Driver for ADI GPIO2 controller
> + *
> + * Copyright 2007-2013 Analog Devices Inc.
> + *
> + * Licensed under the GPLv2 or later
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "core.h"
> +
> +static LIST_HEAD(adi_pint_list);
> +static LIST_HEAD(adi_pinctrl_list);
> +
> +#define PERIPHERAL_USAGE 1
> +#define GPIO_USAGE 0
> +
> +#define DRIVER_NAME "pinctrl-adi2"
> +
> +#define RESOURCE_LABEL_SIZE16
> +#define PINT_HI_OFFSET 16
> +
> +#define RSV_NONE 0
> +#define RSV_GPIO 1
> +#define RSV_INT2
> +#define RSV_PERI 3
> +
> +/**
> + * struct gpio_reserve_map - a GPIO map structure containing the
> + * reservation status of each PIN.
> + *
> + * @owner: who request the reservation
> + * @rsv_gpio: if this pin is reserved as GPIO
> + * @rsv_int: if this pin is reserved as interrupt
> + * @rsv_peri: if this pin is reserved as part of a peripheral device
> + */
> +struct gpio_reserve_map {
> + unsigned char owner[RESOURCE_LABEL_SIZE];
> + bool rsv_gpio;
> + bool rsv_int;
> + bool rsv_peri;
> +};
> +
> +/**
> + * struct gpio_port_saved - GPIO port registers that should be saved between
> + * power suspend and resume operations.
> + *
> + * @fer: PORTx_FER register
> + * @data: PORTx_DATA register
> + * @dir: PORTx_DIR register
> + * @inen: PORTx_INEN register
> + * @mux: PORTx_MUX register
> + */
> +struct gpio_port_saved {
> + u16 fer;
> + u16 data;
> + u16 dir;
> + u16 inen;
> + u32 mux;
> +};
> +
> +/**
> + * struct gpio_pint - GPIO interrupt controller device. Multiple ADI GPIO
> + * banks can be mapped into one GPIO interrupt controller.
> + *
> + * @node: All gpio_pint instances are added to a global list.
> + * @base: GPIO PINT device register base address
> + * @irq: IRQ of the GPIO PINT device, it is the parent IRQ of all
> + * GPIO IRQs mapping to this device.
> + * @domain: [0] irq domain of the gpio port, whose hardware interrupts are
> + * mapping to the low 16-bit of the pint registers.
> + * [1] irq domain of the gpio port, whose hardware interrupts are
> + * mapping to the high 16-bit of the pint registers.
> + * @regs: address pointer to the GPIO PINT device
> + * @map_count: No more than 2 GPIO banks can be mapped to this PINT device.
> + * @lock: This lock make sure the irq_chip operations to one GPIO PINT device
> + *for different GPIO interrrupts are atomic.
> + * @pint_map_port: Set up the mapping between one GPIO PINT device and
> + * multiple GPIO banks.
> + */
> +struct gpio_pint {
> + struct list_head
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote: > We use DT has a kernel configuration input. Our environment is > designed to guarantee 100% that the kernel and DT match exactly. DT > very deliberately isn't an ABI boundary in our systems. It is nice that you use DT in that way, but that is not how DT is supposed to work. If you must keep your DT in sync with the kernel, then there is no advantage over the old platfrom device method. At least that had the virtue of being a C language interface (ABI), and some mistakes were be caught by the compiler. > We've been doing this for years and have a proven in the field track > record of upgrades from pre-2.6.16 to 3.7 and beyond with multiple > SOCs. The same bootloader that was shipped to support non-DT 2.6.16 > boots DT 3.7 just fine. Try that with Freescale PowerPCs. Good luck. Heck, even Paul's OMAP test reports have been spoiled by his not deleting old dtb files. Of course, that is his fault (and not DT's, no never). > For closed system embedded DT has proven *WONDERFUL*. I too work on commercial embedded systems, and DT has proven to be one gigantic *PITA*. Thanks, Richard -- 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] tty: Remove dead code
-> The ledptrs[] array is never initialized.
-> There is no place where kbd->ledmode is set to LED_SHOW_MEM therefore the if
statement does not make much sense.
-> Since LED_SHOW_MEM is not used, it can be removed from the header file as
well.
Signed-off-by: Andreas Platschek
---
drivers/tty/vt/keyboard.c | 21 +
include/linux/kbd_kern.h |3 +--
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index a9af1b9a..d0e3a44 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -132,12 +132,6 @@ static int shift_state = 0;
static unsigned char ledstate = 0xff; /* undefined */
static unsigned char ledioctl;
-static struct ledptr {
- unsigned int *addr;
- unsigned int mask;
- unsigned char valid:1;
-} ledptrs[3];
-
/*
* Notifier list for console keyboard events
*/
@@ -994,24 +988,11 @@ void setledstate(struct kbd_struct *kbd, unsigned int led)
static inline unsigned char getleds(void)
{
struct kbd_struct *kbd = kbd_table + fg_console;
- unsigned char leds;
- int i;
if (kbd->ledmode == LED_SHOW_IOCTL)
return ledioctl;
- leds = kbd->ledflagstate;
-
- if (kbd->ledmode == LED_SHOW_MEM) {
- for (i = 0; i < 3; i++)
- if (ledptrs[i].valid) {
- if (*ledptrs[i].addr & ledptrs[i].mask)
- leds |= (1 << i);
- else
- leds &= ~(1 << i);
- }
- }
- return leds;
+ return kbd->ledflagstate;
}
static int kbd_update_leds_helper(struct input_handle *handle, void *data)
diff --git a/include/linux/kbd_kern.h b/include/linux/kbd_kern.h
index b7c8cdc..c164c04 100644
--- a/include/linux/kbd_kern.h
+++ b/include/linux/kbd_kern.h
@@ -36,10 +36,9 @@ struct kbd_struct {
#define VC_CTRLRLOCK KG_CTRLR/* ctrlr lock mode */
unsigned char slockstate; /* for `sticky' Shift, Ctrl, etc. */
- unsigned char ledmode:2;/* one 2-bit value */
+ unsigned char ledmode:1;
#define LED_SHOW_FLAGS 0/* traditional state */
#define LED_SHOW_IOCTL 1/* only change leds upon ioctl */
-#define LED_SHOW_MEM 2 /* `heartbeat': peek into memory */
unsigned char ledflagstate:4; /* flags, not lights */
unsigned char default_ledflagstate:4;
--
1.7.10.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: [PATCHv2 1/2] iommu/exynos: add devices attached to the System MMU to an IOMMU group
Hi Antonios,
On 25 July 2013 21:04, Antonios Motakis
wrote:
> IOMMU groups are expected by certain users of the IOMMU API,
> e.g. VFIO. Since each device is behind its own System MMU, we
> can allocate a new IOMMU group for each device.
>
> This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> applied on a Linux 3.10.1 kernel.
This kind of meta information should go after the "---" line below.
It has been tested on the Arndale board.
>
> Changes since in v2:
> - Removed possibility for minor memory leak in case of
> misbehaving platform drivers
>
> Signed-off-by: Antonios Motakis
> ---
> drivers/iommu/exynos-iommu.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 51d43bb..c7dd4b5 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1134,6 +1134,32 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
> iommu_domain *domain,
> return phys;
> }
>
> +static int exynos_iommu_add_device(struct device *dev)
> +{
> + struct iommu_group *group;
> + int ret;
> +
> + group = iommu_group_get(dev);
> +
> + if (!group) {
> + group = iommu_group_alloc();
> + if (IS_ERR(group)) {
> + dev_err(dev, "Failed to allocate IOMMU group\n");
> + return PTR_ERR(group);
> + }
> + }
> +
> + ret = iommu_group_add_device(group, dev);
> + iommu_group_put(group);
> +
> + return ret;
> +}
> +
> +static void exynos_iommu_remove_device(struct device *dev)
> +{
> + iommu_group_remove_device(dev);
> +}
> +
> static struct iommu_ops exynos_iommu_ops = {
> .domain_init = _iommu_domain_init,
> .domain_destroy = _iommu_domain_destroy,
> @@ -1142,6 +1168,8 @@ static struct iommu_ops exynos_iommu_ops = {
> .map = _iommu_map,
> .unmap = _iommu_unmap,
> .iova_to_phys = _iommu_iova_to_phys,
> + .add_device = exynos_iommu_add_device,
> + .remove_device = exynos_iommu_remove_device,
> .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> };
>
> --
> 1.8.1.2
>
--
With warm regards,
Sachin
--
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: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Thu, Jul 25, 2013 at 11:53:49AM -0700, Stephen Warren wrote: > On 07/25/2013 11:48 AM, Richard Cochran wrote: > > On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote: > >> > >> As long as we can make sufficiently clear that trying to use an unstable > >> binding is going to be *very* painful, and not necessarily supported. IOW, its okay to break DT setups with every release, as long as we tell people first. Well, at least you are being honest about it now. > That's exactly why we're starting to think about which bindings should > be considered stable and immutable, and when that should happen. As Olof > pointed out, we haven't fully enforced that yet. Preferably bindings > will be marked stable very fast, but mistakes are always going to happen > in early development. ABIs are very hard. They are even harder if you cannot decide what the ABI is in the first place. Thanks, Richard -- 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: Recvfile patch used for Samba.
On Thu, Jul 25, 2013 at 09:17:01AM +0100, Steven Whitehouse wrote: > Hi, > > On Wed, 2013-07-24 at 12:47 +1000, Dave Chinner wrote: > > On Tue, Jul 23, 2013 at 02:58:58PM -0700, Jeremy Allison wrote: > > > Having said that the OEMs that are using it does > > > find it improves write speeds by a large amount (10% > > > or more), so it's showing there is room for improvement > > > here if the correct code can be created for recvfile. > > > > 10% is not very large gain given the complexity it adds, and I > > question that the gain actually comes from moving the memcpy() into > > the kernel. If this recvfile code enabled zero-copy behaviour into > > the page cache, then it would be worth pursuing. But it doesn't, and > > so IMO the complexity is not worth the gain right now. > > > > Indeed, I suspect the 10% gain will be from the multi-page write > > behaviour that was hacked into the code. I wrote a multi-page > > write prototype ~3 years ago that showed write(2) performance gains > > of roughly 10% on low CPU power machines running XFS. ... > > I should probably pick this up again and push it forwards. FWIW, > > I've attached the first multipage-write infrastructure patch from > > the above branch to show how this sort of operation needs to be done > > from a filesystem and page-cache perspective to avoid locking > > problems have sane error handling. > > > > I beleive the version that Christoph implemented for a couple of > > OEMs around that time de-multiplexed the ->iomap method > > I have Christoph's version here and between other tasks, I'm working on > figuring out how it all works and writing GFS2 support for it. I'd more > or less got that complete for your version, but there are a number of > differences with Christoph's code and it is taking me a while to ensure > that I've not missed any corner cases and figuring out how to fit some > of GFS2's odd write modes into the framework, Can you send me Christoph's version so I can have a look at the differences? I'm pretty sure there isn't anything architecturally different, but I've never seen it so I don't know exactly how it differs... Cheers, Dave. -- Dave Chinner da...@fromorbit.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: Linux 3.11-rc2 (acpi backlight, revert)
On 25.07.2013 21:47, Rafael J. Wysocki wrote: Other people who experienced problems with backlight in 3.11-rc2, please let me know whether or not the revert works for you too if you can. Before reverting the patch /sys/class/backlight was empty and backlight brightness was set to max, now it again contains a link to acpi_video0 on my Thinkpad 420s with intel video and adjusting the backlight works again. Joerg -- 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 3/4] msm_serial: Make baud_code detection more dynamic
On Wed, Jul 24, 2013 at 10:37 AM, Stephen Boyd wrote:
> [snip]
> + unsigned int i, divisor;
> + const struct msm_baud_map *entry;
> + static const struct msm_baud_map table[] = {
> + { 1536, 0x00, 1 },
> + { 768, 0x11, 1 },
> + { 384, 0x22, 1 },
> + { 192, 0x33, 1 },
> + { 96, 0x44, 1 },
> + { 48, 0x55, 1 },
> + { 32, 0x66, 1 },
> + { 24, 0x77, 1 },
> + { 16, 0x88, 1 },
> + { 12, 0x99, 6 },
> + {8, 0xaa, 6 },
> + {6, 0xbb, 6 },
> + {4, 0xcc, 6 },
> + {3, 0xdd, 8 },
> + {2, 0xee, 16 },
> + {1, 0xff, 31 },
> + };
> +
> + divisor = uart_get_divisor(port, baud);
> +
> + for (i = 0, entry = table; i < ARRAY_SIZE(table); i++, entry++)
> + if (entry->divisor <= divisor)
> + break;
> +
> + return entry; /* Default to smallest divider */
Shouldn't matter, but you're not defaulting to the smallest divider.
Your are defaulting to an undefined value, as `entry` will be off the
array once i == ARRAY_SIZE().
Regards,
Bjorn
--
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: manual merge of the selinux tree with Linus' tree
I guess my signed off got stripped somewhere. Originally I maintained those
commits but Steve Dickson from red hat picked them up and they then made it
into trond's tree and then into Linus'.
I unfortunately don't have my davequigley.com identities on my iPhone but you
can add a sign off by dpqu...@davequigley.com for the commit.
Sent from my iPhone
On Jul 25, 2013, at 8:48 PM, Stephen Rothwell wrote:
> Hi Eric,
>
> Today's linux-next merge of the selinux tree got a conflict in
> security/selinux/hooks.c between commit eb9ae686507b ("SELinux: Add new
> labeling type native labels") from Linus' tree and commits 40d3d0b85fa2
> ("SELinux: remove crazy contortions around proc") and a64c54cf0811
> ("SELinux: pass a superblock to security_fs_use") from the selinux tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> P.S. Unusually, that commit from Linus' tree has no Signed-off-by from
> its purported author (David Quigley).
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> diff --cc security/selinux/hooks.c
> index a5091ec,4fbf2c5..000
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@@ -680,21 -702,14 +712,19 @@@ static int selinux_set_mnt_opts(struct
> if (strcmp(sb->s_type->name, "proc") == 0)
> sbsec->flags |= SE_SBPROC;
>
> -/* Determine the labeling behavior to use for this filesystem type. */
> -rc = security_fs_use(sb);
> -if (rc) {
> -printk(KERN_WARNING "%s: security_fs_use(%s) returned %d\n",
> - __func__, sb->s_type->name, rc);
> -goto out;
> +if (!sbsec->behavior) {
> +/*
> + * Determine the labeling behavior to use for this
> + * filesystem type.
> + */
> -rc = security_fs_use((sbsec->flags & SE_SBPROC) ?
> -"proc" : sb->s_type->name,
> ->behavior, >sid);
> ++rc = security_fs_use(sb);
> +if (rc) {
> +printk(KERN_WARNING
> +"%s: security_fs_use(%s) returned %d\n",
> +__func__, sb->s_type->name, rc);
> +goto out;
> +}
> }
> -
> /* sets the context of the superblock for the fs being mounted. */
> if (fscontext_sid) {
> rc = may_context_mount_sb_relabel(fscontext_sid, sbsec, cred);
> @@@ -2629,11 -2589,15 +2659,11 @@@ static int selinux_inode_init_security(
> isec->initialized = 1;
> }
>
> -if (!ss_initialized || !(sbsec->flags & SE_SBLABELSUPP))
> +if (!ss_initialized || !(sbsec->flags & SBLABEL_MNT))
> return -EOPNOTSUPP;
>
> -if (name) {
> -namep = kstrdup(XATTR_SELINUX_SUFFIX, GFP_NOFS);
> -if (!namep)
> -return -ENOMEM;
> -*name = namep;
> -}
> +if (name)
> +*name = XATTR_SELINUX_SUFFIX;
>
> if (value && len) {
> rc = security_sid_to_context_force(newsid, , );
--
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: [tip:perf/core] perf tools: Make Power7 events available for perf
On Thu, 25 Jul 2013, Michael Ellerman wrote: > On Tue, Jul 23, 2013 at 05:38:21PM -0400, Vince Weaver wrote: > > Well cursing is what witches do, but if you need someone to swear a bit > I can help you out, I am fuckin Australian after all. I should point out the cursing is directed at the code in question and the overall downhill direction in the perf_event interface, and not directed at anyone personally. I've been fighting a (losing) battle for the past 5 years trying to keep event definitions out of the kernel, I just didn't expect defeat to come so swiftly and so suddenly from an unexpected corner (the power arch). > But there are ~50 generic events in Linux, and our PMU supports ~500. > And our hardware designers use perf, and they need to test all 500 > events. And they're getting sick of using raw event codes. And writing a small wrapper utility or patching perf is somehow harder than sticking the whole mess in the kernel? I get annoyed having to look up the value of ANSI color escape codes now and then, but I don't expect to submit a patch for /sys/tty/colors/red to the kernel and have it accepted. > > Abusing sysfs to waste 100k of non-swappable kernel memory on every > > running Linux kernel everwhere > > It's great that you're so concerned about memory wastage on _powerpc_ > systems. It's a slippery slope. > > Especially as it's likely this becomes stable ABI, and then you'll > > promptly break it as has already happenend in the last kernel release > > with the existing in-kernel powerpc events. > > You're becoming the boy who cried "ABI break" Vince. Yes we renamed one > event, we knew full well that nothing was using it - not even trinity. Yes, the interface has only been around for one kernel version and you've already broken the ABI once. Not a very good track record. Event name renaming is a lot bigger problem on x86 where certain vendors like to fuss with the event names every 3 months or so. trinity is just an example as the users tend to use -rc kernels and thus find the breakages faster. The main problem is tools like PAPI that deal with events in much more critical fashion, but the kernel devs don't really seem to care much about HPC use cases. > > I agree. So why is this patch in tip? > > Because acme picked it up before that thread got going. once a patch gets into tip in my experience all public mailing list review is done with, and the patch is more or less guaranteed to appear in the next major release unless there's some sort of regression in linux-next. Hence this last attempt to get people to discuss this. It will likely be ignored, but at least I can feel like I tried. Vince -- 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 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
Hi Frederic, I apologise for the confusion. As Paul pointed out maybe the usage of the term lapic is causing a large amount of confusion. So please see the clarification below. Maybe it will help answer your question. On 07/26/2013 08:09 AM, Preeti U Murthy wrote: > Hi Frederic, > > On 07/25/2013 07:00 PM, Frederic Weisbecker wrote: >> On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote: >>> In the current design of timer offload framework, the broadcast cpu should >>> *not* go into tickless idle so as to avoid missed wakeups on CPUs in deep >>> idle states. >>> >>> Since we prevent the CPUs entering deep idle states from programming the >>> lapic of the >>> broadcast cpu for their respective next local events for reasons mentioned >>> in >>> PATCH[3/5], the broadcast CPU checks if there are any CPUs to be woken up >>> during >>> each of its timer interrupt programmed to its local events. >>> >>> With tickless idle, the broadcast CPU might not get a timer interrupt till >>> after >>> many ticks which can result in missed wakeups on CPUs in deep idle states. >>> By >>> disabling tickless idle, worst case, the tick_sched hrtimer will trigger a >>> timer interrupt every period to check for broadcast. >>> >>> However the current setup of tickless idle does not let us make the choice >>> of tickless on individual cpus. NOHZ_MODE_INACTIVE which disables tickless >>> idle, >>> is a system wide setting. Hence resort to an arch specific call to check if >>> a cpu >>> can go into tickless idle. >> >> Hi Preeti, >> >> I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle >> mode. >> I read in the previous patch that's because in dynticks idle mode the >> broadcast >> CPU deactivates its lapic so it doesn't receive the IPI. But may be I >> misunderstood. >> Anyway that's not good for powersaving. Firstly, when CPUs enter deep idle states, their local clock event devices get switched off. In the case of powerpc, local clock event device is the decrementer. Hence such CPUs *do not get timer interrupts* but are still *capable of taking IPIs.* So we need to ensure that some other CPU, in this case the broadcast CPU, makes note of when the timer interrupt of the CPU in such deep idle states is to trigger and at that moment issue an IPI to that CPU. *The broadcast CPU however should have its decrementer active always*, meaning it is disallowed from entering deep idle states, where the decrementer switches off, precisely because the other idling CPUs bank on it for the above mentioned reason. > *The lapic of a broadcast CPU is active always*. Say CPUX, wants the > broadcast CPU to wake it up at timeX. Since we cannot program the lapic > of a remote CPU, CPUX will need to send an IPI to the broadcast CPU, > asking it to program its lapic to fire at timeX so as to wake up CPUX. > *With multiple CPUs the overhead of sending IPI, could result in > performance bottlenecks and may not scale well.* Rewording the above. The decrementer of the broadcast CPU is active always. Since we cannot program the clock event device of a remote CPU, CPUX will need to send an IPI to the broadcast CPU, (which the broadcast CPU is very well capable of receiving), asking it to program its decrementer to fire at timeX so as to wake up CPUX *With multiple CPUs the overhead of sending IPI, could result in performance bottlenecks and may not scale well.* > > Hence the workaround is that the broadcast CPU on each of its timer > interrupt checks if any of the next timer event of a CPU in deep idle > state has expired, which can very well be found from dev->next_event of > that CPU. For example the timeX that has been mentioned above has > expired. If so the broadcast handler is called to send an IPI to the > idling CPU to wake it up. > > *If the broadcast CPU, is in tickless idle, its timer interrupt could be > many ticks away. It could miss waking up a CPU in deep idle*, if its > wakeup is much before this timer interrupt of the broadcast CPU. But > without tickless idle, atleast at each period we are assured of a timer > interrupt. At which time broadcast handling is done as stated in the > previous paragraph and we will not miss wakeup of CPUs in deep idle states. > > Yeah it is true that not allowing the broadcast CPU to enter tickless > idle is bad for power savings, but for the use case that we are aiming > at in this patch series, the current approach seems to be the best, with > minimal trade-offs in performance, power savings, scalability and no > change in the broadcast framework that exists today in the kernel. > Regards Preeti U Murthy -- 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 5/5] initmpfs v2: Use initramfs if rootfstype= or root= specified.
On 07/19/2013 02:57:18 PM, Andrew Morton wrote: On Tue, 16 Jul 2013 16:45:39 -0700 (PDT) Rob Landley wrote: > Command line option rootfstype=ramfs to obtain old initramfs behavior, > and use ramfs instead of tmpfs for stub when root= defined (for cosmetic > reasons). Could we get a Documentation/kernel-parameters.txt update please? Sorry for the delay, traveling. Behind on email... "rootfstype" is already documented in kernel parameters: rootfstype= [KNL] Set root filesystem type I just applied the existing definition to initramfs now that it has more than one filesystem option there. Do you want me to add a special case here to say that rootfstype= still works when the root filesystem is initramfs? Or would it instead make more sense to add: Signed-off-by: Rob Landley Document that rootfstype= applies to initmpfs too. --- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt @@ -79,6 +79,9 @@ to just make sure certain lists can't become empty. Most systems just mount another filesystem over rootfs and ignore it. The amount of space an empty instance of ramfs takes up is tiny. +If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by default. +To force ramfs, add "rootfstype=ramfs" to the kernel command line. + What is initramfs? -- (What I _didn't_ do yet is hook up rootflags= to initmpfs, so you can specify size= as something other than 50%. Partly because if you have an empty cpio archive and the rootflags= applies to ext3 or something, those flags could potentially confuse tmpfs with unknown options and throw errors. And partly because mount -o remount,size=20% works fine after the fact, so it's not time critical and I easily can do a follow-up patch. The one potential downside is if you want to have a cpio archive eat more than 50% of the kernel's memory, it'll fail to extract into tmpfs with the size limits. But the rootfstype=ramfs downgrade also works around that for now...) There are a number of follow up patches I could do, but the basic functionality doesn't depend on them... Rob-- 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] driver core: replace strict_strto*() with kstrto*()
The usage of strict_strto*() is not preferred, because
strict_strto*() is obsolete. Thus, kstrto*() should be
used.
Signed-off-by: Jingoo Han
---
Changes since v1:
- mechanically replaced strict_strto*() with kstrto*().
drivers/base/core.c |2 +-
drivers/base/memory.c|4 ++--
drivers/base/power/sysfs.c |2 +-
drivers/base/regmap/regmap-debugfs.c |2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 8856d74..edfbf05 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -38,7 +38,7 @@ long sysfs_deprecated = 0;
#endif
static __init int sysfs_deprecated_setup(char *arg)
{
- return strict_strtol(arg, 10, _deprecated);
+ return kstrtol(arg, 10, _deprecated);
}
early_param("sysfs.deprecated", sysfs_deprecated_setup);
#endif
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 2b7813e..ddd14ce 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -469,7 +469,7 @@ store_soft_offline_page(struct device *dev,
u64 pfn;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- if (strict_strtoull(buf, 0, ) < 0)
+ if (kstrtoull(buf, 0, ) < 0)
return -EINVAL;
pfn >>= PAGE_SHIFT;
if (!pfn_valid(pfn))
@@ -488,7 +488,7 @@ store_hard_offline_page(struct device *dev,
u64 pfn;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- if (strict_strtoull(buf, 0, ) < 0)
+ if (kstrtoull(buf, 0, ) < 0)
return -EINVAL;
pfn >>= PAGE_SHIFT;
ret = memory_failure(pfn, 0, 0);
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index a53ebd2..03e089a 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -206,7 +206,7 @@ static ssize_t autosuspend_delay_ms_store(struct device
*dev,
if (!dev->power.use_autosuspend)
return -EIO;
- if (strict_strtol(buf, 10, ) != 0 || delay != (int) delay)
+ if (kstrtol(buf, 10, ) != 0 || delay != (int) delay)
return -EINVAL;
device_lock(dev);
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 5349575..634164d 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -281,7 +281,7 @@ static ssize_t regmap_map_write_file(struct file *file,
reg = simple_strtoul(start, , 16);
while (*start == ' ')
start++;
- if (strict_strtoul(start, 16, ))
+ if (kstrtoul(start, 16, ))
return -EINVAL;
/* Userspace has been fiddling around behind the kernel's back */
--
1.7.10.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/
linux-next: build failure after merge of the lblnet tree
Hi Paul,
After merging the lblnet tree, today's linux-next build (x86_64
allmodconfig) failed like this:
security/selinux/hooks.c: In function 'sb_finish_set_opts':
security/selinux/hooks.c:448:19: error: 'SE_SBLABELSUPP' undeclared (first use
in this function)
sbsec->flags |= SE_SBLABELSUPP;
^
Caused by commit 8cf9124a324f ("SELinux: Enable setting security contexts
on rootfs inodes") interacting with commit 12f348b9dcf6 ("SELinux: rename
SE_SBLABELSUPP to SBLABEL_MNT") from the selinux tree.
This is not helped by the fact that there are a lot of commits in the
lblnet tree (including 8cf9124a324f) that have been cherry-picked
(instead of being merged) into the selinux tree. :-(
I just reverted the lblnet commit above (since it has been applied twice).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp7Vd8N7aD99.pgp
Description: PGP signature
Re: linux-next: Tree for Jul 25 (ahci_imx.c)
On Fri, Jul 26, 2013 at 03:46:42AM +, Zhu Richard-R65037 wrote: > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Friday, July 26, 2013 2:32 AM > To: Stephen Rothwell > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org; Zhu Richard-R65037 > Subject: Re: linux-next: Tree for Jul 25 (ahci_imx.c) > > On 07/24/13 22:12, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20130724: > > > > on i386: > > # CONFIG_MFD_SYSCON is not set > > > when ahci_imx.c is built as a loadable module: > > ERROR: "syscon_regmap_lookup_by_compatible" [drivers/ata/ahci_imx.ko] > undefined! > > or when it is builtin: > > ahci_imx.c:(.text+0x182e54): undefined reference to > `syscon_regmap_lookup_by_compatible' > We should have it depend on MFD_SYSCON. Shawn -- 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 Jul 25 (ahci_imx.c)
Hi Randy: Thanks for your kindly reminder. I re-produced this issue at my side. Now, I'm trying to find a proper method to fix it. Best Regards Richard Zhu -Original Message- From: Randy Dunlap [mailto:rdun...@infradead.org] Sent: Friday, July 26, 2013 2:32 AM To: Stephen Rothwell Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Zhu Richard-R65037 Subject: Re: linux-next: Tree for Jul 25 (ahci_imx.c) On 07/24/13 22:12, Stephen Rothwell wrote: > Hi all, > > Changes since 20130724: > on i386: # CONFIG_MFD_SYSCON is not set when ahci_imx.c is built as a loadable module: ERROR: "syscon_regmap_lookup_by_compatible" [drivers/ata/ahci_imx.ko] undefined! or when it is builtin: ahci_imx.c:(.text+0x182e54): undefined reference to `syscon_regmap_lookup_by_compatible' Full randconfig file is attached. -- ~Randy -- 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] tools, perf: Add a precise event qualifier v2
On Wed, 24 Jul 2013, Andi Kleen wrote: > Sorry I meant flags as an alias of "the 64bits currently occupied by the > bitfield". Perhaps the name choice was not very good. > > "flags_bitfield" ? > > So the tool would only need to know that, not every bit. > > In theory it could be also generalized as a byte offset to perf_event, > but that may be overengineered. I somehow doubt this would be acceptable. If it were, we could have had a somewhat better interface by just having the event fields be a list of values without involving format/* at all, something like config=0x58034;config1=0x20;precise_ip=0x4 For whatever reason things have to be human readable, and I don't think just having an opaque 64-bit "flags" value will be accepted. I'm likely wrong though, I have a very low accuracy rate for predicting future perf_event design decisions. This is all complicated by the intertwined nature of the perf_event ABI and the perf tool, and the way that there's at least three or four different ways to specify the same event from the perf tool command line. Vince -- 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 18/21] x86, numa: Synchronize nid info in memblock.reserve with numa_meminfo.
On 07/25/2013 11:05 PM, Tejun Heo wrote: Hello, Tang. On Thu, Jul 25, 2013 at 12:09:29PM +0800, Tang Chen wrote: And as in [patch 14/21], when reserving hotpluggable memory, we use pxm. So my Which is kinda nasty. Yes, will remove it. idea was to do a nid sync in numa_init(). After this, memblock will set nid when it allocates memory. Sure, that's the only place we can set the numa node IDs but my point is that you don't need to add another interface. Jet let memblock_set_node() handle both memblock.memory and .reserved ranges. That way, you can make memblock simpler to use and less error-prone. Yes, I missed the isolation phase in memblock_set_node(). So followed. If we want to let memblock_set_node() and alloc functions set nid on the reserved regions, we should setup nid<-> pxm mapping when we parst SRAT for the first time. I don't follow why it has to be different. Why do you need to do anything differently? What am I missing here? No, it was me who missed the isolation phase in memblock_set_node(). 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 17/21] page_alloc, mem-hotplug: Improve movablecore to {en|dis}able using SRAT.
On 07/25/2013 11:09 PM, Tejun Heo wrote: Hello, Tang. On Thu, Jul 25, 2013 at 11:50:12AM +0800, Tang Chen wrote: movablecore boot option was used to specify the size of ZONE_MOVABLE. And this patch-set aims to arrange ZONE_MOVABLE with SRAT info. So my original thinking is to reuse movablecore. Since you said above, I think we have two problems here: 1. Should not let users care about where the hotplug info comes from. 2. Should not distinguish movable node and memory hotplug, since for now, to use memory hotplug is to use movable node. So how about something like "movablenode", just like "quiet" boot option. If users specify "movablenode", then memblock will reserve hotpluggable memory, and create movable nodes if any. If users specify nothing, then the kernel acts as before. Maybe I'm confused but memory hotplug isn't likely to work without this, right? I don't think so. On x86, I think you are right because we cannot hotplug a single memory_block (128MB on x86), which is only a small part of a modern memory device. And now x86 kernel doesn't support a single memory device hotplug, and what we are trying to do is node hotplug. So on x86, memory hotplug won't work without movable node. But on other platform, memory hotplug may work without this. If so, wouldn't it make more sense to have "memory_hotplug" option rather than "movablecore=acpi" which in no way indicates that it has something to do with memory hotplug? I'm not working on ppcm, but I heard that memory hotplug was introduced firstly on ppc, and a memory_block on ppc is only 16MB, which can be hotplugged. It doesn't need movable node support. Here, 16MB memory_block hotplug is not the physical device hotplug, I think. Just logically remove it from one OS, and add it to another OS running on one ppc server. This is done by the hardware. But on x86, we don't have this kind of functionality. A single memory_block hotplug means nothing. Actually I think struct memory_block is useless on x86. But for other platforms, we have to keep this structure. So for the same reason, I think we cannot just introduce a boot option like "memory_hotplug" to enable/disable what we are doing in this patch-set. Sorry I didn't clarify this earlier. 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: [RFC 11/14] powerpc: Eliminate NO_IRQ usage
On Thu, Jul 25, 2013 at 3:58 PM, Geert Uytterhoeven
wrote:
> On Wed, Jan 11, 2012 at 9:22 PM, Grant Likely
> wrote:
>> NO_IRQ is evil. Stop using it in arch/powerpc and powerpc device drivers
>
>> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
>> index 3e06696..55c6ff9 100644
>> --- a/sound/soc/fsl/fsl_ssi.c
>> +++ b/sound/soc/fsl/fsl_ssi.c
>> @@ -666,7 +666,7 @@ static int __devinit fsl_ssi_probe(struct
>> platform_device *pdev)
>> ssi_private->ssi_phys = res.start;
>>
>> ssi_private->irq = irq_of_parse_and_map(np, 0);
>> - if (ssi_private->irq == NO_IRQ) {
>> + if (!ssi_private->irq) {
>> dev_err(>dev, "no irq for node %s\n", np->full_name);
>> ret = -ENXIO;
>> goto error_iomap;
>
> What's the plan with this patch?
>
> This is now failing on xtensa, as it's one of the architectures that doesn't
> define NO_IRQ. Only arm, c6x, mn10300, openrisc, parisc, powerpc, and sparc
> define it.
Wow. I'd pretty much dropped that patch because I didn't have time to
chase it down. It should be pursued though.
In that particular case it is safe I think to apply the change. PPC
defines NO_IRQ to be 0 anyway.
g.
--
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: manual merge of the selinux tree with Linus' tree
Hi Eric,
Today's linux-next merge of the selinux tree got a conflict in
security/selinux/hooks.c between commit eb9ae686507b ("SELinux: Add new
labeling type native labels") from Linus' tree and commits 40d3d0b85fa2
("SELinux: remove crazy contortions around proc") and a64c54cf0811
("SELinux: pass a superblock to security_fs_use") from the selinux tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
P.S. Unusually, that commit from Linus' tree has no Signed-off-by from
its purported author (David Quigley).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc security/selinux/hooks.c
index a5091ec,4fbf2c5..000
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@@ -680,21 -702,14 +712,19 @@@ static int selinux_set_mnt_opts(struct
if (strcmp(sb->s_type->name, "proc") == 0)
sbsec->flags |= SE_SBPROC;
- /* Determine the labeling behavior to use for this filesystem type. */
- rc = security_fs_use(sb);
- if (rc) {
- printk(KERN_WARNING "%s: security_fs_use(%s) returned %d\n",
- __func__, sb->s_type->name, rc);
- goto out;
+ if (!sbsec->behavior) {
+ /*
+ * Determine the labeling behavior to use for this
+ * filesystem type.
+ */
- rc = security_fs_use((sbsec->flags & SE_SBPROC) ?
- "proc" : sb->s_type->name,
- >behavior, >sid);
++ rc = security_fs_use(sb);
+ if (rc) {
+ printk(KERN_WARNING
+ "%s: security_fs_use(%s) returned %d\n",
+ __func__, sb->s_type->name, rc);
+ goto out;
+ }
}
-
/* sets the context of the superblock for the fs being mounted. */
if (fscontext_sid) {
rc = may_context_mount_sb_relabel(fscontext_sid, sbsec, cred);
@@@ -2629,11 -2589,15 +2659,11 @@@ static int selinux_inode_init_security(
isec->initialized = 1;
}
- if (!ss_initialized || !(sbsec->flags & SE_SBLABELSUPP))
+ if (!ss_initialized || !(sbsec->flags & SBLABEL_MNT))
return -EOPNOTSUPP;
- if (name) {
- namep = kstrdup(XATTR_SELINUX_SUFFIX, GFP_NOFS);
- if (!namep)
- return -ENOMEM;
- *name = namep;
- }
+ if (name)
+ *name = XATTR_SELINUX_SUFFIX;
if (value && len) {
rc = security_sid_to_context_force(newsid, , );
pgp_bjiUheEo_.pgp
Description: PGP signature
Re: [PATCH] driver core: replace strict_strto*() with kstrto*()
On Fri, Jul 19, 2013 at 04:21:28PM +0900, Jingoo Han wrote:, Jingoo Han wrote:
>
> The usage of strict_strto*() is not preferred, because
> strict_strto*() is obsolete. Thus, kstrto*() should be
> used.
>
> Signed-off-by: Jingoo Han
> ---
> drivers/base/core.c |2 +-
> drivers/base/memory.c| 10 ++
> drivers/base/power/sysfs.c |7 ++-
> drivers/base/regmap/regmap-debugfs.c |5 +++--
> 4 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 8856d74..edfbf05 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -38,7 +38,7 @@ long sysfs_deprecated = 0;
> #endif
> static __init int sysfs_deprecated_setup(char *arg)
> {
> - return strict_strtol(arg, 10, _deprecated);
> + return kstrtol(arg, 10, _deprecated);
> }
> early_param("sysfs.deprecated", sysfs_deprecated_setup);
> #endif
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 2b7813e..d0817fb 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -469,8 +469,9 @@ store_soft_offline_page(struct device *dev,
> u64 pfn;
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> - if (strict_strtoull(buf, 0, ) < 0)
> - return -EINVAL;
> + ret = kstrtoull(buf, 0, );
> + if (ret < 0)
> + return ret;
In order to not risk any user space breakage,
I will just mechanically replaces strict_strto*() with kstrto*().
> pfn >>= PAGE_SHIFT;
> if (!pfn_valid(pfn))
> return -ENXIO;
> @@ -488,8 +489,9 @@ store_hard_offline_page(struct device *dev,
> u64 pfn;
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> - if (strict_strtoull(buf, 0, ) < 0)
> - return -EINVAL;
> + ret = kstrtoull(buf, 0, );
> + if (ret < 0)
> + return ret;
Ditto.
> pfn >>= PAGE_SHIFT;
> ret = memory_failure(pfn, 0, 0);
> return ret ? ret : count;
> diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> index a53ebd2..e0a3877 100644
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -202,11 +202,16 @@ static ssize_t autosuspend_delay_ms_store(struct device
> *dev,
> struct device_attribute *attr, const char *buf, size_t n)
> {
> long delay;
> + int ret;
>
> if (!dev->power.use_autosuspend)
> return -EIO;
>
> - if (strict_strtol(buf, 10, ) != 0 || delay != (int) delay)
> + ret = kstrtol(buf, 10, );
> + if (ret)
> + return ret;
> +
> + if (delay != (int) delay)
Ditto.
> return -EINVAL;
>
> device_lock(dev);
> diff --git a/drivers/base/regmap/regmap-debugfs.c
> b/drivers/base/regmap/regmap-debugfs.c
> index 5349575..664a75e 100644
> --- a/drivers/base/regmap/regmap-debugfs.c
> +++ b/drivers/base/regmap/regmap-debugfs.c
> @@ -281,8 +281,9 @@ static ssize_t regmap_map_write_file(struct file *file,
> reg = simple_strtoul(start, , 16);
> while (*start == ' ')
> start++;
> - if (strict_strtoul(start, 16, ))
> - return -EINVAL;
> + ret = kstrtoul(start, 16, );
> + if (ret)
> + return ret;
Ditto.
I will send v2 patch, soon.
Thank you.
Best regards,
Jingoo Han
>
> /* Userspace has been fiddling around behind the kernel's back */
> add_taint(TAINT_USER, LOCKDEP_STILL_OK);
> --
> 1.7.10.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 14/21] x86, acpi, numa: Reserve hotpluggable memory at early time.
On 07/25/2013 11:17 PM, Tejun Heo wrote: Hello, On Thu, Jul 25, 2013 at 10:13:21AM +0800, Tang Chen wrote: This is rather hacky. Why not just introduce MEMBLOCK_NO_MERGE flag? The original thinking is to merge regions with the same nid. So I used pxm. And then refresh the nid field when nids are mapped. I will try to introduce MEMBLOCK_NO_MERGE and make it less hacky. I kinda don't follow why it's necessary to disallow merging BTW. Can you plesae elaborate? Shouldn't it be enough to mark the regions hotpluggable? Why does it matter whether they get merged or not? If they belong to different nodes, they'll be separated during the isolation phase while setting nids, which is the modus operandi of memblock anyway. Sorry, I didn't make it clear enough. The reason why disallowing merging is that in [Patch 20/21], I wanted to use the nid in each reserved region to set the start address of ZONE_MOVABLE in each node. And this is only my idea. It is OK without doing this. But as you said, the isolation phase in memblock_set_node() will split the specified region and set the nid, I think it is OK to merge the regions here. I'll just let it merged here, and not store the pxm. In order to let memblock control the allocation, we have to store the hotpluggable ranges somewhere, and keep the allocated range out of the hotpluggable regions. I just think reserving the hotpluggable regions and then memblock won't allocate them. No need to do any other limitation. It isn't different from what you're doing right now. Just tell memblock that the areas are hotpluggable and the default memblock allocation functions stay away from the areas. That way you can later add functions which may allocate from hotpluggable areas for node-local data without resorting to tricks like unreserving part of it and trying allocation or what not. I just don't want to any new variables to store the hotpluggable regions. But without a new shared variable, it seems difficult to achieve the goal you said below. As it currently stands, you're scattering hotpluggable memory handling across memblock and acpi which is kinda nasty. Please make acpi feed information into memblock and make memblock handle hotpluggable regions appropriately. Now, when SRAT is found in acpi side, I reserve the region directly in memblock. I think this is the one you don't like. So how about this. 1. Introduce a new global list used to store hotpluggable regions. 2. On acpi side, find and fulfill the list. 3. On memblock side, make the default allocation function stay away from these regions. And also, the acpi side modification in this patch-set is to get SRAT and parse it. I think most of the logic in acpi_reserve_hotpluggable_memory() is necessary. I don't think letting memblock control the allocation will make the acpi side easier. It's about proper layering. The code change involved in either case aren't big but splitting it right would give us less headache when we later try to support a different firmware or add more features, and more importantly, it makes things logical and lowers the all important WTH factor and makes things easier to follow. OK, followed. 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] workqueue: clear workers of a pool after the CPU is offline
On 07/26/2013 11:07 AM, Tejun Heo wrote: > Hello, > > On Fri, Jul 26, 2013 at 10:13:25AM +0800, Lai Jiangshan wrote: >>> Hmmm... if I'm not confused, now the cpu pools just behave like a >>> normal unbound pool when the cpu goes down, >> >> cpu pools are always referenced, they don't behave like unbound pool. > > Yeah sure, they don't get destroyed but pool management functions the > same. > >>> which means that the idle >>> cpu workers will exit once idle timeout is reached, right? >> >> No, no code to force the cpu workers quit currently. >> you can just offline a cpu to see what happened to the workers. > > Hmmm? The idle timer thing doesn't work? Why? > any worker can't kill itself. managers always tries to leave 2 workers. so the workers of the offline cpu pool can't be totally destroyed. (In old days, we also have idle timer, but the last workers are killed by trustee_thread()) -- 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 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
Hi Paul, On 07/26/2013 08:49 AM, Paul Mackerras wrote: > On Fri, Jul 26, 2013 at 08:09:23AM +0530, Preeti U Murthy wrote: >> Hi Frederic, >> >> On 07/25/2013 07:00 PM, Frederic Weisbecker wrote: >>> Hi Preeti, >>> >>> I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle >>> mode. >>> I read in the previous patch that's because in dynticks idle mode the >>> broadcast >>> CPU deactivates its lapic so it doesn't receive the IPI. But may be I >>> misunderstood. >>> Anyway that's not good for powersaving. >> >> Let me elaborate. The CPUs in deep idle states have their lapics >> deactivated. This means the next timer event which would typically have >> been taken care of by a lapic firing at the appropriate moment does not >> get taken care of in deep idle states, due to the lapic being switched off. > > I really don't think it's helpful to use the term "lapic" in > connection with Power systems. There is nothing that is called a > "lapic" in a Power machine. The nearest equivalent of the LAPIC on > x86 machines is the ICP, the interrupt-controller presentation > element, of which there is one per CPU thread. > > However, I don't believe the ICP gets disabled in deep sleep modes. > What does get disabled is the "decrementer", which is a register that > normally counts down (at 512MHz) and generates an exception when it is > negative. The decrementer *is* part of the CPU core, unlike the ICP. > That's why we can still get IPIs but not timer interrupts. > > Please reword your patch description to not use the term "lapic", > which is not defined in the Power context and is therefore just > causing confusion. Noted. Thank you :) I will probably send out a fresh patchset with the appropriate changelog to avoid this confusion ? > > Paul. > Regards Preeti U murthy -- 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: targetcli -fb now also Apache 2.0 licensed
On 07/24/2013 06:19 PM, Nicholas A. Bellinger wrote: Because -fb has had close to zero peer review, and you've not solicited much input (none from us) before making significant changes to rtslib/targetcli over the past 1 1/2 years. For your own private tree this wouldn't matter. However, for a single upstream tree moving forward, it seems irresponsible to just ask us to sign off on every decision that you've made in -fb with little external review or input. So, to help us get back to a community development model, please cut a -fb branch against upstream rtslib/configshell/targetcli, and start sending the series out for public review. Hi Nick, It's one thing to claim a prerogative of "upstream", but for this to make sense, there needs to be an actual community around the upstream. And if there's going to be submissions for review, then there needs to be someone in charge of the community with a high degree of skill in the code base. Nick you have a great deal of technical expertise around the C code in drivers/target, but Jerome was the one who wrote rtslib, targetcli, and configshell. I believe you can assess the technical aspects of how the user library interacts with the kernel code, but the maintainer should also be extremely conversant in the language the library is written in. In this case, Python. So it's not clear to me if submitting the code would actually result in meaningful code improvements. Also, there has been no effort to sustain a community around this code. There is no bug tracking, no separate mailing list, no regular releases. Debian is running ancient, broken code because nothing's been tagged in over two years. I would love to have you maintain and improve this code, but if you aren't then you can't just say "I'm the upstream bow to me!". We're shipping this code in Fedora and it needs active maintenance. Now that we're all on an even licensing footing, code can flow both ways, and even into your commercial version. So, if you get a Pythonista to maintain upstream, and actually work to build a community around it, then I will play ball. But I must ask you, do you *really* want to maintain this? Forever? In a private thread a while back, RTS CEO Marc said your company's value-add was in different areas now. It might actually be easier for you to hire a Python person to reconcile targetcli-fb with your commercial needs, and then just track it. The objection I have with what you're asking me is that it feels like you're trying to get me to do that reconciliation work for you for free as a condition of being "upstream", and I'm not willing to do work that benefits only your company and not the community at large. Regards -- Andy -- 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: Ugly patches for stolen reservation
On 07/25/2013 07:14 PM, Jesse Barnes wrote: > To clarify: it'll either be marked reserved or not listed at all in e820, > which is why I did this early, before any other e820 stuff like the "RAM > buffer" are allocated, and before we could use the iomem resource (or maybe > we could even early per Linus? I'll check). > > Jesse If it is marked reserved or not listed at all it is much less of an issue. Reserved is in fact the correct thing; not listed at all really isn't very problematic in most cases. -hpa -- 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: [tip:perf/core] perf: Update perf_event_type documentation
On Thu, 25 Jul 2013, Peter Zijlstra wrote: > On Thu, Jul 25, 2013 at 08:34:51AM -0400, Vince Weaver wrote: > > Yes, I meant the addition of the sample_id fields to the existing sample > > values. Though if Peter is right and those have always been there since > > the beginning and just not documented then that won't break anything. > > The commit message wasn't really as clear as it could be. > > /me writes "I shall write better Changelogs." a hundred times. yes, sorry, I shouldn't have been so grumpy about it. After spending 45 minutes digging through the kernel source and other documentation it all makes sense now. The existing manpage even does a mildly accurate job of explaining the situation. It's just I have enough trouble keeping up with the large number of recent perf related patches without having to spend a lot of time decoding cryptic Changelogs. Vince -- 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: __ftrace_hash_rec_update FTRACE_WARN_ON.
On Thu, 2013-07-25 at 14:59 -0400, Steven Rostedt wrote:
> Now that I know what's the problem, it shouldn't be too hard to fix.
It was a bit more involved to fix than I expected. I don't like the fact
that if you filter on only module functions and remove that module, you
now remove the filter and it traces all functions. Oh well, that's the
side effect of removing modules that you are only tracing. If you trace
something other than the module you filter on, it will on remove the
functions that belong to the module but keep the other functions.
So, removing the module, is basically the same as doing:
echo '!:mod:' > set_ftrace_filter
and acts the same, almost. It only affects the filter if the function
trace is currently active. Otherwise it doesn't remove the functions
from the filter, as it only removes functions from active filters. This
is because ftrace is only aware of filters that are activated. I also
added code (set for a separate patch, but combined for this email) that
will add a 64 bit ref counter. Every time a module removes functions
from ftrace, the counter is incremented. If a filter is activated it has
its ref number checked with the current number. If it is different, then
it tests all the functions in its filter to see if any should be removed
(no longer exists).
The reason for the warning, was that we enable the function and it was
mapped in the filter. When we removed the module, we removed its
functions from the table that keeps track of functions being traced (low
level tracking, below filters). But we never cleared the filter. When
the module was added again, it was put back into the same location,
where the filter matched the address, but the low level table had the
function disabled, and the filter said it was enabled. When an update
was made, this discrepancy appeared and caused issues.
You can try this patch to see if it fixes your issues. There may be some
fuzz to apply it because I added it on top of my current queue that
needs to go out for 3.11.
-- Steve
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9f15c00..3e6ed8f 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -114,6 +114,7 @@ struct ftrace_ops {
struct ftrace_hash *notrace_hash;
struct ftrace_hash *filter_hash;
struct mutexregex_lock;
+ u64 mod_cnt;
#endif
};
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 92d3334..366f524 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -93,6 +93,9 @@ struct ftrace_pid {
struct pid *pid;
};
+/* Keep track of modules unloading and ops updating filters */
+static u64 mod_ref_cnt;
+
/*
* ftrace_disabled is set when an anomaly is discovered.
* ftrace_disabled is much stronger than ftrace_enabled.
@@ -321,6 +324,18 @@ static void add_ftrace_ops(struct ftrace_ops **list,
struct ftrace_ops *ops)
rcu_assign_pointer(*list, ops);
}
+#ifdef CONFIG_DYNAMIC_FTRACE
+static void verify_ops(struct ftrace_ops *ops);
+#else
+static inline void verify_ops(struct ftrace_ops *ops) { }
+#endif
+
+static void add_main_ftrace_ops(struct ftrace_ops *ops)
+{
+ verify_ops(ops);
+ add_ftrace_ops(_ops_list, ops);
+}
+
static int remove_ftrace_ops(struct ftrace_ops **list, struct ftrace_ops *ops)
{
struct ftrace_ops **p;
@@ -352,7 +367,7 @@ static void add_ftrace_list_ops(struct ftrace_ops **list,
int first = *list == _list_end;
add_ftrace_ops(list, ops);
if (first)
- add_ftrace_ops(_ops_list, main_ops);
+ add_main_ftrace_ops(main_ops);
}
static int remove_ftrace_list_ops(struct ftrace_ops **list,
@@ -405,7 +420,7 @@ static int __register_ftrace_function(struct ftrace_ops
*ops)
return -ENOMEM;
add_ftrace_list_ops(_control_list, _ops, ops);
} else
- add_ftrace_ops(_ops_list, ops);
+ add_main_ftrace_ops(ops);
if (ftrace_enabled)
update_ftrace_function();
@@ -1351,6 +1366,38 @@ alloc_and_copy_ftrace_hash(int size_bits, struct
ftrace_hash *hash)
return NULL;
}
+static void verify_ops(struct ftrace_ops *ops)
+{
+ struct ftrace_hash *hash;
+ struct hlist_node *tn;
+ struct ftrace_func_entry *entry;
+ int size;
+ int i;
+
+ /*
+* If a module was removed, we may need to verify
+* the filters of this ops.
+*/
+ if (ops->mod_cnt == mod_ref_cnt)
+ return;
+
+ /* We only need to verify the filter that may enable ops */
+ hash = ops->filter_hash;
+ if (ftrace_hash_empty(hash))
+ return;
+
+ size = 1 << hash->size_bits;
+ for (i = 0; i < size; i++) {
+ hlist_for_each_entry_safe(entry, tn, >buckets[i], hlist) {
+ if (!ftrace_location(entry->ip))
+
Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
On Fri, Jul 26, 2013 at 08:09:23AM +0530, Preeti U Murthy wrote: > Hi Frederic, > > On 07/25/2013 07:00 PM, Frederic Weisbecker wrote: > > Hi Preeti, > > > > I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle > > mode. > > I read in the previous patch that's because in dynticks idle mode the > > broadcast > > CPU deactivates its lapic so it doesn't receive the IPI. But may be I > > misunderstood. > > Anyway that's not good for powersaving. > > Let me elaborate. The CPUs in deep idle states have their lapics > deactivated. This means the next timer event which would typically have > been taken care of by a lapic firing at the appropriate moment does not > get taken care of in deep idle states, due to the lapic being switched off. I really don't think it's helpful to use the term "lapic" in connection with Power systems. There is nothing that is called a "lapic" in a Power machine. The nearest equivalent of the LAPIC on x86 machines is the ICP, the interrupt-controller presentation element, of which there is one per CPU thread. However, I don't believe the ICP gets disabled in deep sleep modes. What does get disabled is the "decrementer", which is a register that normally counts down (at 512MHz) and generates an exception when it is negative. The decrementer *is* part of the CPU core, unlike the ICP. That's why we can still get IPIs but not timer interrupts. Please reword your patch description to not use the term "lapic", which is not defined in the Power context and is therefore just causing confusion. Paul. -- 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: [tip:perf/core] perf: Update perf_event_type documentation
On Thu, 25 Jul 2013, Adrian Hunter wrote:
> >> diff --git a/include/uapi/linux/perf_event.h
> >> b/include/uapi/linux/perf_event.h
> >> index 0b1df41..00d8274 100644
> >> --- a/include/uapi/linux/perf_event.h
> >> +++ b/include/uapi/linux/perf_event.h
> >> @@ -478,6 +478,16 @@ enum perf_event_type {
> >> * file will be supported by older perf tools, with these new optional
> >> * fields being ignored.
> >> *
> >> + * struct sample_id {
> >> + * { u32 pid, tid; } && PERF_SAMPLE_TID
> >> + * { u64 time; } && PERF_SAMPLE_TIME
> >> + * { u64 id; } && PERF_SAMPLE_ID
> >> + * { u64 stream_id;} && PERF_SAMPLE_STREAM_ID
> >> + * { u32 cpu, res; } && PERF_SAMPLE_CPU
> >> + * } && perf_event_attr::sample_id_all
> >> + */
> >> +
a thing that personally bothers me are these imaginary struct definitions
added as part of the documentation that aren't actually available in the
public perf_event.h
I can see why it's done, but it can be confusing picking out in later
definitions which struct fields are real and which ones are conceptual.
> >> @@ -498,6 +508,7 @@ enum perf_event_type {
> >> * struct perf_event_headerheader;
> >> * u64 id;
> >> * u64 lost;
> >> + * struct sample_idsample_id;
> >> * };
This is what confused me; this documentation shows the sample_id
as always being there, but in reality that struct is only there
if perf_event_attr::sample_id_all is set.
It might be clearer
if you stuck the perf_event_attr::sample_id_all qualifier each
place you add the sample_id field.
And it's nice that the header holds a size field which ensures backward
compatability, I somehow had forgotten that with my initial complaint.
Vince
--
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: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit 14c5cec5d0cd ("drm/i915:
initialize gt_lock early with other spin locks") from the drm-intel-fixes
tree and commit 907b28c56ea4 ("drm/i915: Colocate all GT access routines
in the same file") from the drm-intel tree.
I fixed it up (using the drm-intel tree version) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp7FvzF7dOop.pgp
Description: PGP signature
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 14c5cec5d0cd ("drm/i915:
initialize gt_lock early with other spin locks") from the drm-intel-fixes
tree and commit 907b28c56ea4 ("drm/i915: Colocate all GT access routines
in the same file") from the drm-intel tree.
I fixed it up (using the drm-intel tree version) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpm_0bcUvXMp.pgp
Description: PGP signature
Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
Hello, On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote: > Sorry if I wasn't clear before, but I need help to at least have new > memblock API support since I am not familiar with memblock code. > I could help in adaptation to the new API for ARM arch and > core kernel code. > > Let me know your thoughts. Unfortunately, I'm currently a bit too occupied to work on it myself. Any volunteers? Thanks. -- tejun -- 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] workqueue: clear workers of a pool after the CPU is offline
Hello, On Fri, Jul 26, 2013 at 10:13:25AM +0800, Lai Jiangshan wrote: > > Hmmm... if I'm not confused, now the cpu pools just behave like a > > normal unbound pool when the cpu goes down, > > cpu pools are always referenced, they don't behave like unbound pool. Yeah sure, they don't get destroyed but pool management functions the same. > > which means that the idle > > cpu workers will exit once idle timeout is reached, right? > > No, no code to force the cpu workers quit currently. > you can just offline a cpu to see what happened to the workers. Hmmm? The idle timer thing doesn't work? Why? -- tejun -- 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 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
Hi Frederic, On 07/25/2013 07:00 PM, Frederic Weisbecker wrote: > On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote: >> In the current design of timer offload framework, the broadcast cpu should >> *not* go into tickless idle so as to avoid missed wakeups on CPUs in deep >> idle states. >> >> Since we prevent the CPUs entering deep idle states from programming the >> lapic of the >> broadcast cpu for their respective next local events for reasons mentioned in >> PATCH[3/5], the broadcast CPU checks if there are any CPUs to be woken up >> during >> each of its timer interrupt programmed to its local events. >> >> With tickless idle, the broadcast CPU might not get a timer interrupt till >> after >> many ticks which can result in missed wakeups on CPUs in deep idle states. By >> disabling tickless idle, worst case, the tick_sched hrtimer will trigger a >> timer interrupt every period to check for broadcast. >> >> However the current setup of tickless idle does not let us make the choice >> of tickless on individual cpus. NOHZ_MODE_INACTIVE which disables tickless >> idle, >> is a system wide setting. Hence resort to an arch specific call to check if >> a cpu >> can go into tickless idle. > > Hi Preeti, > > I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle > mode. > I read in the previous patch that's because in dynticks idle mode the > broadcast > CPU deactivates its lapic so it doesn't receive the IPI. But may be I > misunderstood. > Anyway that's not good for powersaving. > > Also when an arch wants to prevent a CPU from entering dynticks idle mode, it > typically > use arch_needs_cpu(). May be that could fit for you as well? Yes this will suit our requirement perfectly. I will note down this change for the next version of this patchset. Thank you very much for pointing this out :) Regards Preeti U Murthy -- 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: manual merge of the drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 7dcd2677ea91 ("drm/i915:
fix long-standing SNB regression in power consumption after resume v2")
from Linus' tree and commit 59cdb63d529c ("drm/i915: kill
dev_priv->rps.lock") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_dma.c
index 66c6380,6ce9033..000
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@@ -1495,15 -1490,6 +1490,14 @@@ int i915_driver_load(struct drm_device
dev_priv->dev = dev;
dev_priv->info = info;
+ spin_lock_init(_priv->irq_lock);
+ spin_lock_init(_priv->gpu_error.lock);
- spin_lock_init(_priv->rps.lock);
+ spin_lock_init(_priv->gt_lock);
+ spin_lock_init(_priv->backlight.lock);
+ mutex_init(_priv->dpio_lock);
+ mutex_init(_priv->rps.hw_lock);
+ mutex_init(_priv->modeset_restore_lock);
+
i915_dump_device_info(dev_priv);
if (i915_get_bridge_dev(dev)) {
pgpRe2IijizVN.pgp
Description: PGP signature
Re: [PATCH 2/3] Refactor msi/msix restore code Part2
On 2013-07-25 20:25, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 25, 2013 at 02:52:00PM +0800, Zhenzhong Duan wrote:
On 2013-07-24 21:46, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 24, 2013 at 11:08:10AM +0800, Zhenzhong Duan wrote:
xen_initdom_restore_msi_irqs trigger a hypercall to restore addr/data/mask
in dom0. It's better to do the same for default_restore_msi_irqs in baremetal.
Move restore of mask in default_restore_msi_irqs, this could avoid mask
restored twice in dom0, once in hypercall, the other in kernel.
Why not remove the hypercall then?
If removed, msi entry couldn't be restored, such as
pci_reset_function who will reset pci registers.
I did not read your email first time correctly. You are saying
that we restore it twice in the host kernel (aka dom0), once in the
hypervisor (b/c the guest tries to do MSI-X write and it ends up in
the hypervisor), and then we also do it in the guest kernel?
Non business of guest kernel, this patch is fixing driver load issue in
dom0.
Driver qlcnic called pci_reset_function during init. The call path:
pci_reset_function->pci_restore_state->__pci_restore_msix_state->arch_restore_msi_irqs->
xen_initdom_restore_msi_irqs->PHYSDEVOP_restore_msi hypercall
First mask restore is in
xen_initdom_restore_msi_irqs->PHYSDEVOP_restore_msi hypercall
Second restore is __pci_restore_msix_state->msix_mask_irq(entry,
entry->masked)
Mask bits are under full control of xen, and the entry->masked in dom0
kernel is invalid.
We restore an invalid value to mask register could mask the msix interrupt.
That is a lot of duplicate calls.
Or alter the function to detect
whether the restore of the mask has occurred?
Then we need to add the check for dom0 only.
I am not sure I completly follow this. Is the reason for the lost of
interrupt b/c one of those four MSI-X writes ends up masking and the
subsequent writes end up with invalid data?
The first restore in hypercall is needed, and second restore should be
removed for dom0
But baremetal need that restore, so I move it in
default_restore_msi_irqs which is the func for baremetal.
Without that, qlcnic driver calling pci_reset_function will lost interrupt
in dom0.
But if you pass said PCI device to a guest there is no need for the
interrupts to go to the host (dom0). They should go to the hypervisor
which will deliever them to the guest.
Is that what you meant by 'in dom0' ?
Tested-by: Sucheta Chakraborty
Signed-off-by: Zhenzhong Duan
---
drivers/pci/msi.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 87223ae..922fb49 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -216,6 +216,8 @@ void unmask_msi_irq(struct irq_data *data)
#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
void default_restore_msi_irqs(struct pci_dev *dev, int irq)
{
+ int pos;
+ u16 control;
struct msi_desc *entry;
entry = NULL;
@@ -228,8 +230,19 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
entry = irq_get_msi_desc(irq);
}
- if (entry)
+ if (entry) {
write_msi_msg(irq, >msg);
+ if (dev->msix_enabled) {
+ msix_mask_irq(entry, entry->masked);
+ readl(entry->mask_base);
+ } else {
+ pos = entry->msi_attrib.pos;
+ pci_read_config_word(dev, pos + PCI_MSI_FLAGS,
+);
+ msi_mask_irq(entry, msi_capable_mask(control),
+entry->masked);
+ }
+ }
}
#endif
@@ -406,7 +419,6 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
arch_restore_msi_irqs(dev, dev->irq);
pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, );
- msi_mask_irq(entry, msi_capable_mask(control), entry->masked);
Before this patch we had:
write_msi_msg(..)
pci_read_config_work(PCI_MSI_FLAGS, )
pci_write_config_dword(~msi_capable_mask(control) | entry->masked)
control &= ~_PCI_MSI_FLAGS_QSIZE;
control |= ...
pci_write_config_dword(PCI_MSI_FLAGS, control)
while with this you have now:
write_msi_msg(..)
pci_read_config_work(PCI_MSI_FLAGS, &_control)
pci_write_config_dword(~msi_capable_mask(_control) | entry->masked)
--> pci_read_config_work(PCI_MSI_FLAGS, )
control &= ~_PCI_MSI_FLAGS_QSIZE;
control |= ...
pci_write_config_dword(PCI_MSI_FLAGS, control)
see the problem? The 'control' value in __pci_restore_msi_state reads the
value _after_ it has been masked (which is now done in
default_restore_msi_irqs).
Wouldn't that cause problems?
pci_write_config_dword(~msi_capable_mask(_control) | entry->masked) restore per
vector
msi mask bits based on the support of PCI_MSI_FLAGS_MASKBIT. This is different
from the
global mask bit in
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On 07/25/2013 09:49 PM, Joel Fernandes wrote: [..] >> Can I get back on this topic. When USB and ethernet was working for me >> as stated above, I was not doing tftpboot. When I use tftpboot the >> images are obtained from the tftp server, but after kernel has started >> there is nothing in /sys/bus/usb/devices/. > > I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es > and enabled following USB options: > > CONFIG_USB_MUSB_HDRC=y > CONFIG_USB_PHY=y > CONFIG_OMAP_USB2=y > CONFIG_OMAP_CONTROL_USB=y > CONFIG_USB_MUSB_OMAP2PLUS=y > CONFIG_MFD_OMAP_USB_HOST=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > CONFIG_USB_EHCI_HCD_OMAP=y Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y Thanks, -Joel -- 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 v3 1/3] acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, July 25, 2013 8:04 PM
>
> CC-ing some of the tboot maintainers.
> > As what I've said, it's up to the others to determine if the patch is OK.
> > I just need to make my concerns visible in the community. :-)
>
> If I understand your concerns you don't want the hook to depend on any
> of the bit manipulations the existing code does for the pm1 values. The
> hook should do it itself case it needs to tweak them or what not.
>
> And it also frees you from altering the ACPICA code without having to
> worry about being dependent on what the input values the hook requires?
>
> Is this what you had in mind? (not compile tested nor tested).
Actually I've drafted such a patch that had conflicts with the Xen/tboot hooks.
Then the patchset has to first delete the hooks to make test possible for
testers.
It is here:
https://bugzilla.kernel.org/show_bug.cgi?id=54181
>
> I am not even sure if outside the drivers/acpi you can call
> acpi_hw_get_bit_register_info ..
If we want this patch to be accepted without modification, then someone can
help to do such cleanup in the future when ACPICA change happens.
>
> And since the Xen bits would do the same exact bit manipulation it
> probably could use a library to do pm1* stuff so both tboot and Xen
> can use it.
This sounds better.
I think Xen and tboot will need such a library to atomically accessing PM
register fields.
Thanks and best regards
-Lv
>
> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
> index f84fe00..59570b1 100644
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -273,20 +273,75 @@ static void tboot_copy_fadt(const struct
> acpi_table_fadt *fadt)
> offsetof(struct acpi_table_facs, firmware_waking_vector);
> }
>
> -static int tboot_sleep(u8 sleep_state, u32 pm1a_control, u32 pm1b_control)
> +static int tboot_get_pm_control(bool legacy)
> +{
> + u32 pm1a_control;
> + u32 pm1b_control;
> + u32 in_value;
> + acpi_status status;
> + struct acpi_bit_register_info *sleep_type_reg_info;
> + struct acpi_bit_register_info *sleep_enable_reg_info;
> +
> + if (!legacy)
> + return -ENOSPC;
> +
> + status = acpi_hw_register_read(ACPI_REGISTER_PM1_CONTROL,
> +_control);
> + if (ACPI_FAILURE(status)) {
> + return -EXXX /* something */;
> + }
> + sleep_type_reg_info =
> acpi_hw_get_bit_register_info(ACPI_BITREG_SLEEP_TYPE);
> + sleep_enable_reg_info =
> acpi_hw_get_bit_register_info(ACPI_BITREG_SLEEP_ENABLE);
> + /* Clear the SLP_EN and SLP_TYP fields */
> +
> + pm1a_control &= ~(sleep_type_reg_info->access_bit_mask |
> + sleep_enable_reg_info->access_bit_mask);
> + pm1b_control = pm1a_control;
> +
> + /* Insert the SLP_TYP bits */
> +
> + pm1a_control |=
> + (acpi_gbl_sleep_type_a << sleep_type_reg_info->bit_position);
> + pm1b_control |=
> + (acpi_gbl_sleep_type_b << sleep_type_reg_info->bit_position);
> +
> + /*
> + * We split the writes of SLP_TYP and SLP_EN to workaround
> + * poorly implemented hardware.
> + */
> +
> + /* Write #1: write the SLP_TYP data to the PM1 Control registers */
> +
> + status = acpi_hw_write_pm1_control(pm1a_control, pm1b_control);
> + if (ACPI_FAILURE(status)) {
> + return -EXXX /* something */;
> + }
> +
> + /* Insert the sleep enable (SLP_EN) bit */
> +
> + pm1a_control |= sleep_enable_reg_info->access_bit_mask;
> + pm1b_control |= sleep_enable_reg_info->access_bit_mask;
> + tboot->acpi_sinfo.pm1a_cnt_val = pm1a_control;
> + tboot->acpi_sinfo.pm1b_cnt_val = pm1b_control;
> + return 0;
> +}
> +static int tboot_sleep(u8 sleep_state);
> {
> static u32 acpi_shutdown_map[ACPI_S_STATE_COUNT] = {
> /* S0,1,2: */ -1, -1, -1,
> /* S3: */ TB_SHUTDOWN_S3,
> /* S4: */ TB_SHUTDOWN_S4,
> /* S5: */ TB_SHUTDOWN_S5 };
> + int rc;
>
> if (!tboot_enabled())
> return 0;
>
> tboot_copy_fadt(_gbl_FADT);
> - tboot->acpi_sinfo.pm1a_cnt_val = pm1a_control;
> - tboot->acpi_sinfo.pm1b_cnt_val = pm1b_control;
> +
> + rc = tboot_get_pm_control();
> + if (rc < 0)
> + return -1;
> /* we always use the 32b wakeup vector */
> tboot->acpi_sinfo.vector_width = 32;
>
> diff --git a/drivers/acpi/acpica/hwesleep.c b/drivers/acpi/acpica/hwesleep.c
> index 5e5f762..a8e98f9 100644
> --- a/drivers/acpi/acpica/hwesleep.c
> +++ b/drivers/acpi/acpica/hwesleep.c
> @@ -113,6 +113,15 @@ acpi_status acpi_hw_extended_sleep(u8
> sleep_state)
> !acpi_gbl_FADT.sleep_status.address) {
> return_ACPI_STATUS(AE_NOT_EXIST);
> }
> + /*
> +* If using tboot or other platforms that need tweaks then
> +* do them here, and also bail out if
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
Hi Arend, On 07/25/2013 08:06 AM, Arend van Spriel wrote: > On 07/18/2013 02:42 PM, Roger Quadros wrote: >> On 07/18/2013 03:38 PM, Arend van Spriel wrote: >>> On 07/18/2013 01:30 PM, Roger Quadros wrote: On 07/18/2013 02:24 PM, Arend van Spriel wrote: > On 07/18/2013 01:18 PM, Roger Quadros wrote: >> Hi Arend, >> >> On 07/18/2013 11:41 AM, Arend van Spriel wrote: >>> Hi Tony, >>> >>> >>> We are using the panda board (es variant) for testing our SDIO >>> based chips. For this we have an adapter card connection to >>> expansion connector A. As this adapter is not publicly available >>> we had internally patched board-omap4panda.c. Also we follow the >>> -rc releases and use TFTP to boot the kernel image which requires >>> USB. >>> >>> Moving to 3.11-rc1 I found that the mentioned board file was >>> removed by your commit: >>> >>> commit b42b918194c4791510ac049e3d507169a7de8544 >>> Author: Tony Lindgren >>> Date: Thu May 30 12:53:05 2013 -0700 >>> >>>ARM: OMAP2+: Remove board-omap4panda.c >>> >>> As our patches on that file are internal I do not hold it against >>> you. This is no regression and we need to fix it. >>> >>> So my first step was to follow the recipe given in that commit. >>> Beside that I noticed a thread about USB issue on LKML so I also >>> applied the following commit: >>> >>> commit 352f573e59050c7a604c35c58b4bbfc51edebbee >>> Author: Roger Quadros >>> Date: Tue Jun 18 19:04:47 2013 +0300 >>> >>>ARM: OMAP2+: Provide alias to USB PHY clock >>> >>> The attached kernel log seems to suggest that the device tree is >>> picked up by the kernel, but the USB does not seem very active. >>> No ethernet connectivity. This does seem a regression to me. Is >>> there some other patch that I need to get it going again? >>> >> >> I tried with your config and 3.11-rc1 kernel with the above commit >> on top and ethernet seems to >> work for me. My boot log is attached. >> >> Are you sure that you are building the DTB for panda-es and the >> bootloader is picking up the right file and >> not an outdated one? > > I appended the DTB to the kernel image thus avoiding the need to > update u-boot (at least that is what I understood from Tony's commit). > I understand this can be a little tedious at first. This is my u-boot boot.txt fatload mmc 0:1 0x825f omap4-panda-es.dtb fatload mmc 0:1 0x8030 uImage set fdt_high 0x setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 rootwait bootm 0x8030 - 0x825f You need to generate boot.scr from the above boot.txt and place it in SD card boot partition. mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr And of course copy the omap4-panda-es.dtb to SD card boot partition. hope this helps. >>> >>> Thanks for sharing this. >>> >> Why is the version of SPL loader and u-boot different in your log? >> You need to use the MLO file generated by the u-boot build along >> with the uImage. >> >> Just to be sure we are on the same setup could you please try with >> latest u-boot release (2013-04). Thanks. > > I recall having difficulty with TFTP boot using a 2013 u-boot > release, but that hurdle is for later. I will try. > OK. We can figure this out as well. >>> >>> I tried with same SPL and u-boot version, but that did not work out. >>> So I moved to v2013.04 and the log looks better. I was especially >>> interested in this: >>> >>> [2.807434] usb 1-1.1: new high-speed USB device number 3 using >>> ehci-omap >>> [2.932495] usb 1-1.1: New USB device found, idVendor=0424, >>> idProduct=ec00 >>> [2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, >>> SerialNumbe0 >>> [2.958770] smsc95xx v1.0.4 >>> Starting logging: OK >>> Initializing random number generator... [3.045806] smsc95xx >>> 1-1.1:1.0 eth0 >> >> Cool! :). >> >> FYI. I also tested tftpboot from u-boot and NFS root file system and >> it works fine. > > Hi Roger, > > Can I get back on this topic. When USB and ethernet was working for me > as stated above, I was not doing tftpboot. When I use tftpboot the > images are obtained from the tftp server, but after kernel has started > there is nothing in /sys/bus/usb/devices/. I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es and enabled following USB options: CONFIG_USB_MUSB_HDRC=y CONFIG_USB_PHY=y CONFIG_OMAP_USB2=y CONFIG_OMAP_CONTROL_USB=y CONFIG_USB_MUSB_OMAP2PLUS=y CONFIG_MFD_OMAP_USB_HOST=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_EHCI_HCD_OMAP=y With this I see both USB ports, and ethernet: bash-4.2# ifconfig eth0 eth0 Link encap:Ethernet HWaddr
Re: [PATCH] xfs: introduce object readahead to log recovery
On Thu, Jul 25, 2013 at 04:23:39PM +0800, zwu.ker...@gmail.com wrote:
> From: Zhi Yong Wu
>
> It can take a long time to run log recovery operation because it is
> single threaded and is bound by read latency. We can find that it took
> most of the time to wait for the read IO to occur, so if one object
> readahead is introduced to log recovery, it will obviously reduce the
> log recovery time.
>
> In dirty log case as below:
> data device: 0xfd10
> log device: 0xfd10 daddr: 20480032 length: 20480
>
> log tail: 7941 head: 11077 state:
That's only a small log (10MB). As I've said on irc, readahead won't
show any real difference on this and you need to be testing with
large logs.
>
> This dirty ratio is about 15%. I am trying to do tests in larger scale
> and dirtier filesystem environment.
>
> Log recovery time stat:
>
> w/o this patchw/ this patch
> real 0m1.051s 0m0.965s
> sys 0m0.033s 0m0.035s
>
> iowait 0m1.018s 0m0.930s
Well, it's not made much of a difference there. That's probably
within the noise of repeated log recovery runs.
My simple test is:
$ cat recovery_time.sh
#!/bin/bash
cd /home/dave/src/compilebench-0.6/
mkfs.xfs -f /dev/vdc;
mount /dev/vdc /mnt/scratch
chmod 777 /mnt/scratch;
./compilebench --no-sync -D /mnt/scratch &
sleep 55
/home/dave/src/xfstests-dev/src/godown /mnt/scratch
umount /mnt/scratch
xfs_logprint -t /dev/vdc |head -20
time mount /dev/vdc /mnt/scratch
umount /mnt/scratch
$
And the recovery time from this is between 15-17s:
log device: 0xfd20 daddr: 107374182032 length: 4173824
^^^ almost 2GB
log tail: 19288 head: 264809 state:
real0m17.913s
user0m0.000s
sys 0m2.381s
And runs at 3-4000 read IOPs for most of that time. It's largely IO
bound, even on SSDs.
With your patch:
log tail: 35871 head: 308393 state:
real0m12.715s
user0m0.000s
sys 0m2.247s
And it peaked at ~5000 read IOPS.
It's definitely an improvement, but there's a lot of dead time still
spent waiting for IO that we should be able to remove. Let's have a
look at the code...
> +STATIC void
> +xlog_recover_inode_ra_pass2(
> + struct xlog *log,
> + struct xlog_recover_item*item)
> +{
> + xfs_inode_log_format_t *in_f;
> + xfs_mount_t *mp = log->l_mp;
> + int error;
> + int need_free = 0;
> +
> + if (item->ri_buf[0].i_len == sizeof(xfs_inode_log_format_t)) {
> + in_f = item->ri_buf[0].i_addr;
> + } else {
> + in_f = kmem_alloc(sizeof(xfs_inode_log_format_t), KM_SLEEP);
> + need_free = 1;
> + error = xfs_inode_item_format_convert(>ri_buf[0], in_f);
> + if (error)
> + goto error;
> + }
I'd just put the conversion buffer on stack and avoid the need to
alloc/free memory here. There's plenty of stack space available
during recovery here, so let's use it to keep the overhead of
readahead down.
> +STATIC void
> +xlog_recover_dquot_ra_pass2(
> + struct xlog *log,
> + struct xlog_recover_item*item)
> +{
> + xfs_mount_t *mp = log->l_mp;
> + xfs_buf_t *bp;
> + struct xfs_disk_dquot *recddq;
> + int error;
> + xfs_dq_logformat_t *dq_f;
> + uinttype;
> +
> +
> + if (mp->m_qflags == 0)
> + return;
> +
> + recddq = item->ri_buf[1].i_addr;
> + if (recddq == NULL)
> + return;
> + if (item->ri_buf[1].i_len < sizeof(xfs_disk_dquot_t))
> + return;
> +
> + type = recddq->d_flags & (XFS_DQ_USER | XFS_DQ_PROJ | XFS_DQ_GROUP);
> + ASSERT(type);
> + if (log->l_quotaoffs_flag & type)
> + return;
> +
> + dq_f = item->ri_buf[0].i_addr;
> + ASSERT(dq_f);
> + error = xfs_qm_dqcheck(mp, recddq, dq_f->qlf_id, 0, XFS_QMOPT_DOWARN,
> +"xlog_recover_dquot_ra_pass2 (log copy)");
> + if (error)
> + return;
> + ASSERT(dq_f->qlf_len == 1);
> +
> + error = xfs_trans_read_buf(mp, NULL, mp->m_ddev_targp, dq_f->qlf_blkno,
> +XFS_FSB_TO_BB(mp, dq_f->qlf_len), 0, ,
> +NULL);
> + if (!error)
> + xfs_buf_relse(bp);
> +}
That's not doing readahead - that's an integrity check followed by a
blocking read. Shouldn't it just be calling xfs_buf_readahead() on
dq_f->qlf_blkno/dq_f->qlf_len, after checking whether it had been
cancelled?
> STATIC int
> xlog_recover_commit_pass1(
> struct xlog *log,
> @@ -3140,10 +3255,14 @@ xlog_recover_commit_pass2(
> struct xlog *log,
> struct xlog_recover *trans,
> struct list_head
Re: [62/85] HID: apple: Add support for the 2013 Macbook Air
On Thu, 2013-07-25 at 08:50 +0200, rydb...@euromail.se wrote: > Hi Ben, > > > 3.2.49-rc1 review patch. If anyone has any objections, please let me know. > > Because the bcm5974 patch is unsuitable for pre-3.7 kernels, this one > is unsuitable as well; it renders the trackpad unusable. Without this > patch, we at least have one-finger mouse emulation, so, please remove > from the queue. That's a pity. I'll drop them both, thanks. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
Hi Frederic, On 07/25/2013 07:00 PM, Frederic Weisbecker wrote: > On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote: >> In the current design of timer offload framework, the broadcast cpu should >> *not* go into tickless idle so as to avoid missed wakeups on CPUs in deep >> idle states. >> >> Since we prevent the CPUs entering deep idle states from programming the >> lapic of the >> broadcast cpu for their respective next local events for reasons mentioned in >> PATCH[3/5], the broadcast CPU checks if there are any CPUs to be woken up >> during >> each of its timer interrupt programmed to its local events. >> >> With tickless idle, the broadcast CPU might not get a timer interrupt till >> after >> many ticks which can result in missed wakeups on CPUs in deep idle states. By >> disabling tickless idle, worst case, the tick_sched hrtimer will trigger a >> timer interrupt every period to check for broadcast. >> >> However the current setup of tickless idle does not let us make the choice >> of tickless on individual cpus. NOHZ_MODE_INACTIVE which disables tickless >> idle, >> is a system wide setting. Hence resort to an arch specific call to check if >> a cpu >> can go into tickless idle. > > Hi Preeti, > > I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle > mode. > I read in the previous patch that's because in dynticks idle mode the > broadcast > CPU deactivates its lapic so it doesn't receive the IPI. But may be I > misunderstood. > Anyway that's not good for powersaving. Let me elaborate. The CPUs in deep idle states have their lapics deactivated. This means the next timer event which would typically have been taken care of by a lapic firing at the appropriate moment does not get taken care of in deep idle states, due to the lapic being switched off. Hence such CPUs offload their next timer event to the broadcast CPU, which should *not* enter deep idle states. The broadcast CPU has the responsibility of waking the CPUs in deep idle states. *The lapic of a broadcast CPU is active always*. Say CPUX, wants the broadcast CPU to wake it up at timeX. Since we cannot program the lapic of a remote CPU, CPUX will need to send an IPI to the broadcast CPU, asking it to program its lapic to fire at timeX so as to wake up CPUX. *With multiple CPUs the overhead of sending IPI, could result in performance bottlenecks and may not scale well.* Hence the workaround is that the broadcast CPU on each of its timer interrupt checks if any of the next timer event of a CPU in deep idle state has expired, which can very well be found from dev->next_event of that CPU. For example the timeX that has been mentioned above has expired. If so the broadcast handler is called to send an IPI to the idling CPU to wake it up. *If the broadcast CPU, is in tickless idle, its timer interrupt could be many ticks away. It could miss waking up a CPU in deep idle*, if its wakeup is much before this timer interrupt of the broadcast CPU. But without tickless idle, atleast at each period we are assured of a timer interrupt. At which time broadcast handling is done as stated in the previous paragraph and we will not miss wakeup of CPUs in deep idle states. Yeah it is true that not allowing the broadcast CPU to enter tickless idle is bad for power savings, but for the use case that we are aiming at in this patch series, the current approach seems to be the best, with minimal trade-offs in performance, power savings, scalability and no change in the broadcast framework that exists today in the kernel. > > Also when an arch wants to prevent a CPU from entering dynticks idle mode, it > typically > use arch_needs_cpu(). May be that could fit for you as well? Oh ok thanks :) I will look into this and get back on if we can use it. Regards Preeti U Murthy -- 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 resend] shdma: fixup sh_dmae_get_partial() calculation error
On Wed, Jul 24, 2013 at 10:43:44AM +0200, Guennadi Liakhovetski wrote: > Hi Morimoto-san > > On Tue, 23 Jul 2013, Kuninori Morimoto wrote: > > > sh_desc->hw.tcr is controlling real data size, > > and, register TCR is controlling data transfer count > > which was xmit_shifted value of hw.tcr. > > Current sh_dmae_get_partial() is calculating in different unit. > > This patch fixes it. > > > > Signed-off-by: Kuninori Morimoto > > Looks right to me > > Acked-by: Guennadi Liakhovetski Thanks, I will queue this up for v3.11 in the fixes-for-v3.11 branch. -- 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] regulator:pfuze100: fix build warning and correct the binding doc
fix building warning and correct the binding doc
Signed-off-by: Robin Gong
---
.../devicetree/bindings/regulator/pfuze100.txt |2 ++
drivers/regulator/pfuze100-regulator.c |2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt
b/Documentation/devicetree/bindings/regulator/pfuze100.txt
index 22e1a48..fc989b2 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.txt
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -3,6 +3,8 @@ PFUZE100 family of regulators
Required properties:
- compatible: "fsl,pfuze100"
- reg: I2C slave address
+
+Required child node:
- regulators: This is the list of child nodes that specify the regulator
initialization data for defined regulators. Please refer to below doc
Documentation/devicetree/bindings/regulator/regulator.txt.
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index fcc7cd0..e2f9dcf 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -295,7 +295,7 @@ static inline struct device_node *match_of_node(int index)
#else
static int pfuze_parse_regulators_dt(struct pfuze_chip *chip)
{
- return NULL;
+ return 0;
}
static inline struct regulator_init_data *match_init_data(int index)
--
1.7.5.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 -next] staging: gdm724x: use GFP_ATOMIC under spin lock
From: Wei Yongjun A spin lock is taken here so we should use GFP_ATOMIC. Signed-off-by: Wei Yongjun --- drivers/staging/gdm724x/gdm_mux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/gdm724x/gdm_mux.c b/drivers/staging/gdm724x/gdm_mux.c index f570bc0..7becf5c 100644 --- a/drivers/staging/gdm724x/gdm_mux.c +++ b/drivers/staging/gdm724x/gdm_mux.c @@ -410,7 +410,7 @@ static int gdm_mux_send(void *priv_dev, void *data, int len, int tty_index, gdm_mux_send_complete, t); - ret = usb_submit_urb(t->urb, GFP_KERNEL); + ret = usb_submit_urb(t->urb, GFP_ATOMIC); spin_unlock_irqrestore(_dev->write_lock, flags); -- 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 RESEND 0/1] AHCI: Optimize interrupt processing
On Thu, Jul 25 2013, Nicholas A. Bellinger wrote: > On Thu, 2013-07-25 at 12:16 +0200, Alexander Gordeev wrote: > > On Mon, Jul 22, 2013 at 02:10:36PM -0700, Nicholas A. Bellinger wrote: > > > Np. FYI, you'll want to use the latest commit e7827b351 HEAD from > > > target-pending/scsi-mq, which now has functioning scsi-generic support. > > > > Survives a boot, a kernel build and the build's result :) > > Great. Thanks for the feedback Alexander! > > So the next step on my end is to enable -mq for ahci, and verify initial > correctness using QEMU/KVM hardware emulation. > > Btw, I've been looking at enabling the SHT->cmd_size for struct > ata_queued_cmd descriptor pre-allocation, but AFAICT these descriptors > are already all pre-allocated by libata and obtained via ata_qc_new() -> > __ata_qc_from_tag() during ata_scsi_queuecmd(). Might still not be a bad idea to do it: - Cleans up a driver, getting rid of the need to alloc, maintain, and free those structures. - Should be some cache locality benefits to having it all sequential. > So that said, with the struct request + struct scsi_cmnd pre-allocations > already provided by blk-mq -> scsi-mq code, all memory allocations > should have already been eliminated from I/O fast path. Nice! -- Jens Axboe -- 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] workqueue: clear workers of a pool after the CPU is offline
On 07/25/2013 11:31 PM, Tejun Heo wrote: > Hello, Lai. > > On Thu, Jul 25, 2013 at 06:52:02PM +0800, Lai Jiangshan wrote: >> The unbound pools and their workers can be destroyed/cleared >> when their refcnt become zero. But the cpu pool can't be destroyed >> due to they are always referenced, their refcnt are always > 0. >> >> We don't want to destroy the cpu pools, but we want to destroy >> the workers of the pool when the pool is full idle after the cpu >> is offline. This is the default behavior in old days until >> we removed the trustee_thread(). >> >> We need to find a new way to restore this behavior, >> We add offline_pool() and POOL_OFFLINE flag to do so. > > Hmmm... if I'm not confused, now the cpu pools just behave like a > normal unbound pool when the cpu goes down, cpu pools are always referenced, they don't behave like unbound pool. > which means that the idle > cpu workers will exit once idle timeout is reached, right? No, no code to force the cpu workers quit currently. you can just offline a cpu to see what happened to the workers. > I really > don't think it'd be worthwhile to add extra logic to accelerate the > process. > > Note that there actually are benefits to doing it asynchronously as > CPUs go up and down very frequently on mobile platforms and destroying > idle workers as soon as possible would just mean that we'd be doing a > lot of work which isn't necessary. I mean, we even grew an explicit > mechanism to park kthreads to avoid repeatedly creating and destroying > per-cpu kthreads as cpus go up and down. I don't see any point in > adding code to go the other direction. > > 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] usb: dwc3: core: modify IO memory resource after deferred probe completes
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Thursday, July 25, 2013 1:52 PM
>
> On Thu, Jul 25, 2013 at 07:46:58PM +, Paul Zimmerman wrote:
> > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > index 607bef8..50c833f 100644
> > > --- a/drivers/usb/dwc3/core.c
> > > +++ b/drivers/usb/dwc3/core.c
> > > @@ -384,21 +384,6 @@ static int dwc3_probe(struct platform_device *pdev)
> > > dev_err(dev, "missing memory resource\n");
> > > return -ENODEV;
> > > }
> > > - dwc->xhci_resources[0].start = res->start;
> > > - dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
> > > - DWC3_XHCI_REGS_END;
> > > - dwc->xhci_resources[0].flags = res->flags;
> > > - dwc->xhci_resources[0].name = res->name;
> > > -
> > > - res->start += DWC3_GLOBALS_REGS_START;
> > > -
> > > - /*
> > > - * Request memory region but exclude xHCI regs,
> > > - * since it will be requested by the xhci-plat driver.
> > > - */
> > > - regs = devm_ioremap_resource(dev, res);
> > > - if (IS_ERR(regs))
> > > - return PTR_ERR(regs);
> > >
> > > if (node) {
> > > dwc->maximum_speed = of_usb_get_maximum_speed(node);
> > > @@ -452,6 +437,22 @@ static int dwc3_probe(struct platform_device *pdev)
> > > return -EPROBE_DEFER;
> > > }
> > >
> > > + dwc->xhci_resources[0].start = res->start;
> > > + dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
> > > + DWC3_XHCI_REGS_END;
> > > + dwc->xhci_resources[0].flags = res->flags;
> > > + dwc->xhci_resources[0].name = res->name;
> > > +
> > > + res->start += DWC3_GLOBALS_REGS_START;
> >
> > Ick. The driver is modifying the struct resource passed to it by the
>
> heh...
>
> > platform code? That seems like a layering violation, and is fragile as
> > hell. In addition to this bug, what would happen if the struct resource
> > was declared 'const'?
>
> nothing would happen if it was declared const since platform_add_device
> makes a copy of what was declared, and that's always non-const.
OK.
> Also, this is not *modifying* what was passed, just skipping the xHCI
> address space so we don't request_mem_region() an area we won't really
> handle and prevent xhci-hcd.ko from probing.
Hmm? platform_get_resource() returns a pointer to an entry in the
platform_device's resource[] array. And "res->start +=" modifies the
entry pointed at. If it didn't, the bug fixed by this patch wouldn't
have happened.
Are you sure this code will work OK if you build the driver as a module,
modprobe it, rmmod it, and then modprobe it again? Seems like it won't,
unless the dev->resource[] array gets reinitialized in between somehow.
All this assumes I'm reading the code correctly, of course. If I'm not,
then never mind :)
--
Paul
--
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 an assertion failure
On Thu, Jul 25, 2013 at 09:38:44PM +0800, zwu.ker...@gmail.com wrote:
> From: Zhi Yong Wu
>
> When running the compilebench, one assertion failure was found.
> This related line of code was introduced by commit 5f6bed76c0.
>
> commit 5f6bed76c0c85cb4d04885a5de00b629deee550b
> Author: Dave Chinner
> Date: Thu Jun 27 16:04:52 2013 +1000
>
> xfs: Introduce an ordered buffer item
Ok, so the assert was introduced there, and for good reason: if we
are about to free the xfs_buf_log_item, then it better not still be
referenced by the AIL.
> XFS: Assertion failed: !(bip->bli_item.li_flags & XFS_LI_IN_AIL), file:
> fs/xfs/xfs_buf_item.c, line: 942
> [ cut here ]
> kernel BUG at fs/xfs/xfs_message.c:108!
> invalid opcode: [#1] SMP
> Modules linked in:
> CPU: 0 PID: 40 Comm: kworker/u2:1 Not tainted 3.11.0-rc2+ #955
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> Workqueue: writeback bdi_writeback_workfn (flush-8:0)
> [] xfs_buf_item_relse+0x4f/0xd0
> [] xfs_buf_item_unlock+0x18b/0x1e0
> [] xfs_trans_free_items+0x7d/0xb0
> [] xfs_trans_cancel+0x13c/0x1b0
> [] xfs_iomap_write_allocate+0x249/0x350
> [] xfs_map_blocks+0x2e2/0x350
> [] xfs_vm_writepage+0x236/0x5e0
And what we see here is a buffer item being released and freed after
a cancelled allocation transaction while it is in the AIL. That's
indicative of a bug in the buffer item code, and will cause
user-after-free issues. Hence:
> diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
> index bfc4e0c..b4d42ae 100644
> --- a/fs/xfs/xfs_buf_item.c
> +++ b/fs/xfs/xfs_buf_item.c
> @@ -939,7 +939,6 @@ xfs_buf_item_relse(
> xfs_buf_log_item_t *bip = bp->b_fspriv;
>
> trace_xfs_buf_item_relse(bp, _RET_IP_);
> - ASSERT(!(bip->bli_item.li_flags & XFS_LI_IN_AIL));
Removing the assert is not going to fix the bug that it is telling
us is ocurring.
Indeed, it points out that the calling code - xfs_buf_item_unlock()
- is probably doing the wrong this. i.e. that it assumes that a
clean buffer item is only referenced in this transaction and so it
can unconditionally free it. That's an invalid assumption, and
exactly the situation that the above assert was designed to catch.
Can you try the patch below? It should fix the problem
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
xfs: use reference counts to free clean buffer items
From: Dave Chinner
When a transaction is cancelled and the buffer log item is clean in
the transaction, the buffer log item is unconditionally freed. If
the log item is in the AIL, however, this leads to a use after free
condition as the item still has other users.
In this case, xfs_buf_item_relse() should only be called on clean
buffer items if the reference count has dropped to zero. This
ensures only the last user frees the item.
Signed-off-by: Dave Chinner
---
fs/xfs/xfs_buf_item.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
index 9358504..3a944b1 100644
--- a/fs/xfs/xfs_buf_item.c
+++ b/fs/xfs/xfs_buf_item.c
@@ -613,11 +613,9 @@ xfs_buf_item_unlock(
}
}
}
- if (clean)
- xfs_buf_item_relse(bp);
- else if (aborted) {
+ if (clean || aborted) {
if (atomic_dec_and_test(>bli_refcount)) {
- ASSERT(XFS_FORCED_SHUTDOWN(lip->li_mountp));
+ ASSERT(!aborted || XFS_FORCED_SHUTDOWN(lip->li_mountp));
xfs_buf_item_relse(bp);
}
} 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/
Should unprivileged linkat(..., AT_EMPTY_PATH) work on O_TMPFILE files?
The change:
commit f4e0c30c191f87851c4a53454abb55ee276f4a7e
Author: Al Viro
Date: Tue Jun 11 08:34:36 2013 +0400
allow the temp files created by open() to be linked to
O_TMPFILE | O_CREAT => linkat() with AT_SYMLINK_FOLLOW and /proc/self/fd/
as oldpath (i.e. flink()) will create a link
O_TMPFILE | O_CREAT | O_EXCL => ENOENT on attempt to link those guys
Signed-off-by: Al Viro
makes it possible to hardlink an O_TMPFILE file using procfs. Should
linkat(fd, "", newdirfd, newpath, AT_EMPTY_PATH) also work?
AFAICS it currently requires CAP_DAC_READ_SEARCH, but I'm a bit
confused as to why linkat(..., AT_EMPTY_PATH) should have a stricter
check than linkat(AT_FDCWD, "/proc/self/fd/n", ...,
AT_SYMLINK_FOLLOW), (The relevant change is
11a7b371b64ef39fc5fb1b6f2218eef7c4d035e3.)
FWIW, this program works on Linux 3.9, which makes me doubt that the
security restriction on linkat is doing any good:
#include
#include
#include
#include
int main(int argc, char **argv)
{
char buf[128];
if (argc != 3)
errx(1, "Usage: flink FD PATH");
sprintf(buf, "/proc/self/fd/%d", atoi(argv[1]));
if (linkat(AT_FDCWD, buf, AT_FDCWD, argv[2], AT_SYMLINK_FOLLOW) != 0)
err(1, "linkat");
return 0;
}
Removing the check from the AT_EMPTY_PATH case would simplify code
that wants to write a file, fsync it, and then flink it in.
--Andy
P.S. For even more fun, I'd *love* a linkat flag that would allow the
destination to be overwritten, but that's a different can of worms.
--
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 06/13] ACPI/IPMI: Add reference counting for ACPI operation region handlers
> From: Rafael J. Wysocki [mailto:r...@sisk.pl] > Sent: Friday, July 26, 2013 5:29 AM > > On Tuesday, July 23, 2013 04:09:43 PM Lv Zheng wrote: > > This patch adds reference couting for ACPI operation region handlers to fix > > races caused by the ACPICA address space callback invocations. > > > > ACPICA address space callback invocation is not suitable for Linux > > CONFIG_MODULE=y execution environment. > > Actually, can you please explain to me what *exactly* the problem is? OK. I'll add race explanations in the next revision. The problem is there is no "lock" held inside ACPICA for invoking operation region handlers. Thus races happens between the acpi_remove/install_address_space_handler and the handler/setup callbacks. This is correct per ACPI specification. As if there is interpreter locks held for invoking operation region handlers, the timeout implemented inside the operation region handlers will make all locking facilities (Acquire or Sleep,...) timed out. Please refer to ACPI specification "5.5.2 Control Method Execution": Interpretation of a Control Method is not preemptive, but it can block. When a control method does block, OSPM can initiate or continue the execution of a different control method. A control method can only assume that access to global objects is exclusive for any period the control method does not block. So it is pretty much likely that ACPI IO transfers are locked inside the operation region callback implementations. Using locking facility to protect the callback invocation will risk dead locks. Thanks -Lv > Rafael
systemtap 2.3 release
The systemtap team announces release 2.3, "jbnq fdhvjjry"!
improved pass-2 error messages, runtime preprocessor conditionals,
global module variable visibility, internal improvements,
colorized error messages, uprobe pre-filtering, re-written
regular expression support
= Where to get it
http://sourceware.org/systemtap/ - our project page
http://sourceware.org/systemtap/ftp/releases/systemtap-2.3.tar.gz
http://koji.fedoraproject.org/koji/packageinfo?packageID=615
git tag release-2.3 (commit e5813857)
There have been over 200 commits since the last release.
There have been over 50 bugs fixed / features added since the last
release.
= How to build it
See the README and NEWS files at
http://sourceware.org/git/?p=systemtap.git;a=tree
Further information at http://sourceware.org/systemtap/wiki/
= Systemtap frontend (stap) changes
- java("org.my.MyApp") probes are now restricted to pre-existing jvm
pid's with a listing in jps -l output to avoid recursive calls
- Alternative functions are now suggested when function probes could
not be resolved. For example, kernel.function("vfs_reads") will
suggest vfs_read. Other probes for which suggestions are made are
module.function, process.function, and process.library.function.
- Has life been a bit bland lately? Want to spice things up? Why not
write a few faulty probes and feast your eyes upon the myriad of
colours adorning your terminal as SystemTap softly whispers in your
ear... 'parse error'. Search for '--color' in 'man stap' for more
info.
- systemtap's dyninst runtime now allows use of the -c command
parameter to target runtime over the course of a process
- global module variables are now available to probe with the @var
syntax
= Systemtap script language changes
- A "runtime" preprocessor conditional has been added as follows:
%( runtime == "kernel" %?
# do something we can only do in kernel mode
%)
%( runtime == "dyninst" %?
# ...
%)
- The notation @var("varname@cuname", "module") is used for accessing
global variables. If the cuname is not specified, then all cu's are
searched
- Support for the Posix ERE named character classes has been added to
the regexp engine, e.g. [:digit:], [:alpha:]
= Systemtap runtime changes
- The java backend now requires the targeted process to be pre-existing.
- Systemtap now makes use of the kernel uprobes pre-filtering to call
UPROBE_HANDLER_REMOVE for any process that happens to share the same
inode. This removes unwanted overhead on unrelated processes.
- A substantial internal overhaul of the regexp engine has resulted in
correct behaviour on further obscure edge cases. The regexp engine
now implements the ERE standard and correctly passes the testsuite
for the glibc regexp engine (minus portions corresponding to
unimplemented features -- i.e. subexpression capture and reuse).
= Systemtap tapset changes
- New tapsets:
rcu.stp Read-copy-update lock tapset
- Changed tapsets:
context.stp added various process context functions
target_set.stp created(func equiv of linux/target_set.stp)
aux_syscalls.stpupdated for latest kernel changes
guru-signal.stp created(ability to raise a signal in the
current thread)
nd_syscalls.stp use sigaltstack probe alias when
CONFIG_GENERIC_SIGALTSTACK is set or
when on kernel v3.9+
syscalls.stpditto
ipmib.stp updated probe aliases
nd_syscalls.stp 'syscall.{execve,compat_execve}' on newer
kernels, use of CONFIG_GENERIC_SIGNALSTACK
nd_syscalls2.stpditto
nfs_proc.stpAbstract use of nfs_{read,write,commit}_data
structs in macro file
nfs_proc.stpm said macro file
rpc.stp updated aliases
socket.stp function deprecations (see NEWS) and use of
macros
syscalls.stpFix 'syscall.{execve,compat_execve}'
syscalls2.stp Break {nd_}syscall.rt_sigprocmask into
'rt_sigprocmask' and 'compat_rt_sigprocmask'
target_set.stp use process.{begin,end} probes to better
track the process
tcp.stp make use of ntohs() function for return values
tcpmib.stp ditto
ucontext.stpproperly error/warn if _stp_umod_lookup fails
udp.stp add source/dest ip/port variables
string.stp adds error checking
tzinfo.stp split into dyninst and linux implementation
tapsets
uconversions.stperror checking improvements and added
user_string2_warn and user_string2_n_warn
- The function user_string() has been superseded by the function
user_string_quoted()
Re: SATA hotplug not detecting new disks
On 07/26/2013 07:15 AM, Dave Hansen wrote: > I've got a relatively new system that doesn't seem to be able to hotplug > SATA disks. I see the same behavior on 3.10, 3.11-rc2, and Ubuntu's > 3.8.0-25-generic. The disks are detected right away on reboots, but > even after poking the /sys/class/scsi_host/host*/scan files, new disks > are never detected. I've disabled link power management. > > Am I doing something stupid here? I thought this "just worked" on my > previous hardware. My vague memory reminds me that not all SATA ports are hot pluggable - you can check the port's "External SATA port" bit and "Hot Plug Capable" bit of the PxCMD register like this: $ grep ahci /proc/iomem e1a4-e1a407ff : ahci # dd if=/dev/mem of=ahcidump bs=4096 count=1 skip=0xe1a40 You will need to change 0xe1a40 to decimal format. Then the PxCMD is at offset 0x118 for port 0, check bit 21 for E-SATA or bit 18 for hot pluggable bits. If any of them set to 1, this port should be hot pluggable; otherwise, it doesn't have this capability. > > The motherboard is an Intel DH87RL. The SATA controller is: > >> 00:1f.2 SATA controller: Intel Corporation Lynx Point 6-port SATA Controller >> 1 [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0]) >> Subsystem: Intel Corporation Device 204a >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- >> SERR- > Latency: 0 >> Interrupt: pin B routed to IRQ 41 >> Region 0: I/O ports at f0d0 [size=8] >> Region 1: I/O ports at f0c0 [size=4] >> Region 2: I/O ports at f0b0 [size=8] >> Region 3: I/O ports at f0a0 [size=4] >> Region 4: I/O ports at f060 [size=32] >> Region 5: Memory at f7d3a000 (32-bit, non-prefetchable) [size=2K] >> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- >> Address: fee2200c Data: 4191 >> Capabilities: [70] Power Management version 3 >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA >> PME(D0-,D1-,D2-,D3hot+,D3cold-) >> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=0004 >> Kernel driver in use: ahci > > Relevant dmesg from boot: > > ahci :00:1f.2: version 3.0 > ahci :00:1f.2: irq 41 for MSI/MSI-X > ahci :00:1f.2: AHCI 0001.0300 32 slots 5 ports 6 Gbps 0x1e impl SATA > mode > ahci :00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst This doesn't have sxs(support external sata) bit here, so no ports from this host is E-SATA port. Only need to check the hot pluggable bit. Hope this helps, -Aaron > ahci :00:1f.2: setting latency timer to 64 > scsi0 : ahci > scsi1 : ahci > scsi2 : ahci > scsi3 : ahci > scsi4 : ahci > ata1: DUMMY > ata2: SATA max UDMA/133 abar m2048@0xf7d3a000 port 0xf7d3a180 irq 41 > ata3: SATA max UDMA/133 abar m2048@0xf7d3a000 port 0xf7d3a200 irq 41 > ata4: SATA max UDMA/133 abar m2048@0xf7d3a000 port 0xf7d3a280 irq 41 > ata5: SATA max UDMA/133 abar m2048@0xf7d3a000 port 0xf7d3a300 irq 41 > -- 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 03/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI transfers
> From: Corey Minyard [mailto:tcminy...@gmail.com] > Sent: Friday, July 26, 2013 8:48 AM > > On 07/25/2013 07:16 PM, Zheng, Lv wrote: > >> > >> If I understand this correctly, the problem would be if: > >> > >> rem_time = wait_for_completion_timeout(_msg->tx_complete, > >> IPMI_TIMEOUT); > >> > >> returns on a timeout, then checks msg_done and races with something > >> setting msg_done. If that is the case, you would need the smp_rmb() > >> before checking msg_done. > >> > >> However, the timeout above is unnecessary. You are using > >> ipmi_request_settime(), so you can set the timeout when the IPMI > >> command fails and returns a failure message. The driver guarantees a > >> return message for each request. Just remove the timeout from the > >> completion, set the timeout and retries in the ipmi request, and the > >> completion should handle the barrier issues. > > It's just difficult for me to determine retry count and timeout value, maybe > retry=0, timeout=IPMI_TIMEOUT is OK. > > The code of the timeout completion is already there, I think the quick fix > > code > should not introduce this logic. > > I'll add a new patch to apply your comment. > > Since it is a local BMC, I doubt a retry is required. That is probably fine. > Or > you could set retry=1 and timeout=IPMI_TIMEOUT/2 if you wanted to be more > sure, but I doubt it would make a difference. The only time you really need > to > worry about retries is if you are resetting the BMC or it is being overloaded. I think for ACPI IPMI operation region, retries can be implemented in the ASL codes by the BIOS. I'll check if retry=0 is correct. > > > > >> Plus, from a quick glance at the code, it doesn't look like it will > >> properly handle a situation where the timeout occurs and is handled > >> then the response comes in later. > > PATCH 07 fixed this issue. > > Here we just need the smp_rmb() or holding tx_msg_lock() around the > acpi_format_ipmi_response(). > > If you apply the fix like I suggest, then the race goes away. If there's no > timeout and it just waits for the completion, things get a lot simpler. Exactly. I'll try to apply this in this patch, then the PATCH 07 is also need to be re-worked. Thanks and best regards -Lv > > > > Thanks for commenting. > > No problem, thanks for working on this. > > -corey
RE: [PATCH 08/13] ACPI/IPMI: Cleanup several acpi_ipmi_device members
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, July 26, 2013 6:26 AM
>
> On Tuesday, July 23, 2013 04:10:06 PM Lv Zheng wrote:
> > This is a trivial patch:
> > 1. Deletes a member of the acpi_ipmi_device - smi_data which is not
> >actually used.
> > 2. Updates a member of the acpi_ipmi_device - pnp_dev which is only used
> >by dev_warn() invocations, so changes it to struct device.
> >
> > Signed-off-by: Lv Zheng
> > Reviewed-by: Huang Ying
> > ---
> > drivers/acpi/acpi_ipmi.c | 30 ++
> > 1 file changed, 14 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c index
> > 0ee1ea6..7f93ffd 100644
> > --- a/drivers/acpi/acpi_ipmi.c
> > +++ b/drivers/acpi/acpi_ipmi.c
> > @@ -63,11 +63,10 @@ struct acpi_ipmi_device {
> > struct list_head tx_msg_list;
> > spinlock_t tx_msg_lock;
> > acpi_handle handle;
> > - struct pnp_dev *pnp_dev;
> > + struct device *dev;
> > ipmi_user_t user_interface;
> > int ipmi_ifnum; /* IPMI interface number */
> > long curr_msgid;
> > - struct ipmi_smi_info smi_data;
> > atomic_t refcnt;
> > };
> >
> > @@ -132,7 +131,7 @@ static struct ipmi_driver_data driver_data = { };
> >
> > static struct acpi_ipmi_device *
> > -ipmi_dev_alloc(int iface, struct ipmi_smi_info *smi_data, acpi_handle
> > handle)
> > +ipmi_dev_alloc(int iface, struct device *pdev, acpi_handle handle)
>
> Why is the second arg called pdev?
OK, I will change it to dev.
>
> > {
> > struct acpi_ipmi_device *ipmi_device;
> > int err;
> > @@ -148,14 +147,13 @@ ipmi_dev_alloc(int iface, struct ipmi_smi_info
> *smi_data, acpi_handle handle)
> > spin_lock_init(_device->tx_msg_lock);
> >
> > ipmi_device->handle = handle;
> > - ipmi_device->pnp_dev = to_pnp_dev(get_device(smi_data->dev));
> > - memcpy(_device->smi_data, smi_data, sizeof(struct
> ipmi_smi_info));
> > + ipmi_device->dev = get_device(pdev);
> > ipmi_device->ipmi_ifnum = iface;
> >
> > err = ipmi_create_user(iface, _data.ipmi_hndlrs,
> >ipmi_device, );
> > if (err) {
> > - put_device(smi_data->dev);
> > + put_device(pdev);
> > kfree(ipmi_device);
> > return NULL;
> > }
> > @@ -175,7 +173,7 @@ acpi_ipmi_dev_get(struct acpi_ipmi_device
> > *ipmi_device) static void ipmi_dev_release(struct acpi_ipmi_device
> > *ipmi_device) {
> > ipmi_destroy_user(ipmi_device->user_interface);
> > - put_device(ipmi_device->smi_data.dev);
> > + put_device(ipmi_device->dev);
> > kfree(ipmi_device);
> > }
> >
> > @@ -263,7 +261,7 @@ static int acpi_format_ipmi_request(struct
> acpi_ipmi_msg *tx_msg,
> > buffer = (struct acpi_ipmi_buffer *)value;
> > /* copy the tx message data */
> > if (buffer->length > ACPI_IPMI_MAX_MSG_LENGTH) {
> > - dev_WARN_ONCE(_msg->device->pnp_dev->dev, true,
> > + dev_WARN_ONCE(tx_msg->device->dev, true,
> > "Unexpected request (msg len %d).\n",
> > buffer->length);
> > return -EINVAL;
> > @@ -382,11 +380,11 @@ static void ipmi_msg_handler(struct
> ipmi_recv_msg *msg, void *user_msg_data)
> > struct acpi_ipmi_device *ipmi_device = user_msg_data;
> > int msg_found = 0;
> > struct acpi_ipmi_msg *tx_msg;
> > - struct pnp_dev *pnp_dev = ipmi_device->pnp_dev;
> > + struct device *dev = ipmi_device->dev;
> > unsigned long flags;
> >
> > if (msg->user != ipmi_device->user_interface) {
> > - dev_warn(_dev->dev,
> > + dev_warn(dev,
> > "Unexpected response is returned. returned user %p,
> > expected
> user %p\n",
> > msg->user, ipmi_device->user_interface);
> > goto out_msg;
> > @@ -404,7 +402,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg
> *msg, void *user_msg_data)
> > spin_unlock_irqrestore(_device->tx_msg_lock, flags);
> >
> > if (!msg_found) {
> > - dev_warn(_dev->dev,
> > + dev_warn(dev,
> > "Unexpected response (msg id %ld) is returned.\n",
> > msg->msgid);
> > goto out_msg;
> > @@ -412,7 +410,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg
> > *msg, void *user_msg_data)
> >
> > /* copy the response data to Rx_data buffer */
> > if (msg->msg.data_len > ACPI_IPMI_MAX_MSG_LENGTH) {
> > - dev_WARN_ONCE(_dev->dev, true,
> > + dev_WARN_ONCE(dev, true,
> > "Unexpected response (msg len %d).\n",
> > msg->msg.data_len);
> > goto out_comp;
> > @@ -431,7 +429,7 @@ out_msg:
> > static void ipmi_register_bmc(int iface, struct device *dev) {
> > struct acpi_ipmi_device *ipmi_device, *temp;
> > - struct pnp_dev *pnp_dev;
> > + struct device *pdev;
>
> And here?
The dev is the parameter of the
RE: [PATCH 07/13] ACPI/IPMI: Add reference counting for ACPI IPMI transfers
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Friday, July 26, 2013 6:23 AM
>
> On Tuesday, July 23, 2013 04:09:54 PM Lv Zheng wrote:
> > This patch adds reference counting for ACPI IPMI transfers to tune the
> > locking granularity of tx_msg_lock.
> >
> > The acpi_ipmi_msg handling is re-designed using referece counting.
> > 1. tx_msg is always unlinked before complete(), so that:
> >1.1. it is safe to put complete() out side of tx_msg_lock;
> >1.2. complete() can only happen once, thus smp_wmb() is not required.
> > 2. Increasing the reference of tx_msg before calling
> >ipmi_request_settime() and introducing tx_msg_lock protected
> >ipmi_cancel_tx_msg() so that a complete() can happen in parellel with
> >tx_msg unlinking in the failure cases.
> > 3. tx_msg holds the reference of acpi_ipmi_device so that it can be flushed
> >and freed in the contexts other than acpi_ipmi_space_handler().
> >
> > The lockdep_chains shows all acpi_ipmi locks are leaf locks after the
> > tuning:
> > 1. ipmi_lock is always leaf:
> >irq_context: 0
> >[81a943f8] smi_watchers_mutex
> >[a06eca60] driver_data.ipmi_lock
> >irq_context: 0
> >[82767b40] >mutex
> >[a00a6678] s_active#103
> >[a06eca60] driver_data.ipmi_lock
> > 2. without this patch applied, lock used by complete() is held after
> >holding tx_msg_lock:
> >irq_context: 0
> >[82767b40] >mutex
> >[a00a6678] s_active#103
> >[a06ecce8] &(_device->tx_msg_lock)->rlock
> >irq_context: 1
> >[a06ecce8] &(_device->tx_msg_lock)->rlock
> >irq_context: 1
> >[a06ecce8] &(_device->tx_msg_lock)->rlock
> >[a06eccf0] >wait#25
> >irq_context: 1
> >[a06ecce8] &(_device->tx_msg_lock)->rlock
> >[a06eccf0] >wait#25
> >[81e36620] >pi_lock
> >irq_context: 1
> >[a06ecce8] &(_device->tx_msg_lock)->rlock
> >[a06eccf0] >wait#25
> >[81e36620] >pi_lock
> >[81e5d0a8] >lock
> > 3. with this patch applied, tx_msg_lock is always leaf:
> >irq_context: 0
> >[82767b40] >mutex
> >[a00a66d8] s_active#107
> >[a07ecdc8] &(_device->tx_msg_lock)->rlock
> >irq_context: 1
> >[a07ecdc8] &(_device->tx_msg_lock)->rlock
> >
> > Signed-off-by: Lv Zheng
> > Cc: Zhao Yakui
> > Reviewed-by: Huang Ying
> > ---
> > drivers/acpi/acpi_ipmi.c | 107
> +-
> > 1 file changed, 77 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
> > index 2a09156..0ee1ea6 100644
> > --- a/drivers/acpi/acpi_ipmi.c
> > +++ b/drivers/acpi/acpi_ipmi.c
> > @@ -105,6 +105,7 @@ struct acpi_ipmi_msg {
> > u8 data[ACPI_IPMI_MAX_MSG_LENGTH];
> > u8 rx_len;
> > struct acpi_ipmi_device *device;
> > + atomic_trefcnt;
>
> Again: kref, please?
Please see the concerns in another email.
>
> > };
> >
> > /* IPMI request/response buffer per ACPI 4.0, sec 5.5.2.4.3.2 */
> > @@ -195,22 +196,47 @@ static struct acpi_ipmi_device
> *acpi_ipmi_get_selected_smi(void)
> > return ipmi_device;
> > }
> >
> > -static struct acpi_ipmi_msg *acpi_alloc_ipmi_msg(struct acpi_ipmi_device
> *ipmi)
> > +static struct acpi_ipmi_msg *ipmi_msg_alloc(void)
> > {
> > + struct acpi_ipmi_device *ipmi;
> > struct acpi_ipmi_msg *ipmi_msg;
> > - struct pnp_dev *pnp_dev = ipmi->pnp_dev;
> >
> > + ipmi = acpi_ipmi_get_selected_smi();
> > + if (!ipmi)
> > + return NULL;
> > ipmi_msg = kzalloc(sizeof(struct acpi_ipmi_msg), GFP_KERNEL);
> > - if (!ipmi_msg) {
> > - dev_warn(_dev->dev, "Can't allocate memory for ipmi_msg\n");
> > + if (!ipmi_msg) {
> > + acpi_ipmi_dev_put(ipmi);
> > return NULL;
> > }
> > + atomic_set(_msg->refcnt, 1);
> > init_completion(_msg->tx_complete);
> > INIT_LIST_HEAD(_msg->head);
> > ipmi_msg->device = ipmi;
> > +
> > return ipmi_msg;
> > }
> >
> > +static struct acpi_ipmi_msg *
> > +acpi_ipmi_msg_get(struct acpi_ipmi_msg *tx_msg)
> > +{
> > + if (tx_msg)
> > + atomic_inc(_msg->refcnt);
> > + return tx_msg;
> > +}
> > +
> > +static void ipmi_msg_release(struct acpi_ipmi_msg *tx_msg)
> > +{
> > + acpi_ipmi_dev_put(tx_msg->device);
> > + kfree(tx_msg);
> > +}
> > +
> > +static void acpi_ipmi_msg_put(struct acpi_ipmi_msg *tx_msg)
> > +{
> > + if (tx_msg && atomic_dec_and_test(_msg->refcnt))
> > + ipmi_msg_release(tx_msg);
> > +}
> > +
> > #defineIPMI_OP_RGN_NETFN(offset) ((offset >> 8) & 0xff)
> > #defineIPMI_OP_RGN_CMD(offset) (offset & 0xff)
> > static int acpi_format_ipmi_request(struct acpi_ipmi_msg *tx_msg,
> > @@ -300,7 +326,7 @@ static void
Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
Hi Neil, > Sorry I'm a bit late to the thread, I've ben swamped. Has someone > tested this with kexec/kdump? Thats why the origional patch was > created, because when kexec loads the kernel at a different physical > address, the relocations messed with the module crc's, and modules > couldn't load during the kexec boot. Assuming that kernaddr_start > gets set appropriately during boot, using PHYSICAL_START should be > fine, but I wanted to check, and don't currently have access to a > powerpc system to do so. Neil I tested a relocatable kernel forced to run at a non zero physical address (ie basically kdump). I verified CRCs were bad with your original patch backed out, and were good with this patch applied. 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/
linux-next: manual merge of the ia64 tree with the pci-current tree
Hi all,
Today's linux-next merge of the ia64 tree got conflicts in
arch/ia64/configs/generic_defconfig,
arch/ia64/configs/gensparse_defconfig, arch/ia64/configs/tiger_defconfig
and arch/ia64/configs/xen_domu_defconfig between commit eeaa9b427947
("PCI: hotplug: Convert to be builtin only, not modular") from the
pci-current tree and commit 5da8f68fb699 ("[IA64] Change
CONFIG_HOTPLUG_PCI_ACPI=m to =y") from the ia64 tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/ia64/configs/generic_defconfig
index efbd292,a4bd0ef..000
--- a/arch/ia64/configs/generic_defconfig
+++ b/arch/ia64/configs/generic_defconfig
@@@ -31,8 -31,8 +31,8 @@@ CONFIG_ACPI_FAN=
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_CONTAINER=m
-CONFIG_HOTPLUG_PCI=m
+CONFIG_HOTPLUG_PCI=y
- CONFIG_HOTPLUG_PCI_ACPI=m
+ CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
diff --cc arch/ia64/configs/gensparse_defconfig
index f64980d,5e5f074..000
--- a/arch/ia64/configs/gensparse_defconfig
+++ b/arch/ia64/configs/gensparse_defconfig
@@@ -25,8 -25,8 +25,8 @@@ CONFIG_ACPI_BUTTON=
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_CONTAINER=m
-CONFIG_HOTPLUG_PCI=m
+CONFIG_HOTPLUG_PCI=y
- CONFIG_HOTPLUG_PCI_ACPI=m
+ CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
diff --cc arch/ia64/configs/tiger_defconfig
index 0f4e9e4,7049c3d..000
--- a/arch/ia64/configs/tiger_defconfig
+++ b/arch/ia64/configs/tiger_defconfig
@@@ -31,8 -31,8 +31,8 @@@ CONFIG_ACPI_BUTTON=
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_CONTAINER=m
-CONFIG_HOTPLUG_PCI=m
+CONFIG_HOTPLUG_PCI=y
- CONFIG_HOTPLUG_PCI_ACPI=m
+ CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
diff --cc arch/ia64/configs/xen_domu_defconfig
index b025acf,7dc6ed7..000
--- a/arch/ia64/configs/xen_domu_defconfig
+++ b/arch/ia64/configs/xen_domu_defconfig
@@@ -32,8 -32,8 +32,8 @@@ CONFIG_ACPI_BUTTON=
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_CONTAINER=m
-CONFIG_HOTPLUG_PCI=m
+CONFIG_HOTPLUG_PCI=y
- CONFIG_HOTPLUG_PCI_ACPI=m
+ CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
pgpbWkvJoSY7w.pgp
Description: PGP signature
RE: [PATCH 04/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI user
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, July 26, 2013 5:59 AM
>
> On Tuesday, July 23, 2013 04:09:26 PM Lv Zheng wrote:
> > This patch uses reference counting to fix the race caused by the
> > unprotected ACPI IPMI user.
> >
> > As the acpi_ipmi_device->user_interface check in
> > acpi_ipmi_space_handler() can happen before setting user_interface to
> > NULL and codes after the check in acpi_ipmi_space_handler() can happen
> > after user_interface becoming NULL, then the on-going
> > acpi_ipmi_space_handler() still can pass an invalid
> > acpi_ipmi_device->user_interface to ipmi_request_settime(). Such race
> > condition is not allowed by the IPMI layer's API design as crash will
> > happen in
> ipmi_request_settime().
> > In IPMI layer, smi_gone()/new_smi() callbacks are protected by
> > smi_watchers_mutex, thus their invocations are serialized. But as a
> > new smi can re-use the freed intf_num, it requires that the callback
> > implementation must not use intf_num as an identification mean or it
> > must ensure all references to the previous smi are all dropped before
> > exiting
> > smi_gone() callback. In case of acpi_ipmi module, this means
> > ipmi_flush_tx_msg() must ensure all on-going IPMI transfers are
> > completed before exiting ipmi_flush_tx_msg().
> >
> > This patch follows ipmi_devintf.c design:
> > 1. Invoking ipmi_destroy_user() after the reference count of
> >acpi_ipmi_device dropping to 0, this matches IPMI layer's API calling
> >rule on ipmi_destroy_user() and ipmi_request_settime().
> > 2. References of acpi_ipmi_device dropping to 1 means tx_msg related to
> >this acpi_ipmi_device are all freed, this can be used to implement the
> >new flushing mechanism. Note complete() must be retried so that the
> >on-going tx_msg won't block flushing at the point to add tx_msg into
> >tx_msg_list where reference of acpi_ipmi_device is held. This matches
> >the IPMI layer's callback rule on smi_gone()/new_smi() serialization.
> > 3. ipmi_flush_tx_msg() is performed after deleting acpi_ipmi_device from
> >the list so that no new tx_msg can be created after entering flushing
> >process.
> > 4. The flushing of tx_msg is also moved out of ipmi_lock in this patch.
> >
> > The forthcoming IPMI operation region handler installation changes
> > also requires acpi_ipmi_device be handled in the reference counting style.
> >
> > Authorship is also updated due to this design change.
> >
> > Signed-off-by: Lv Zheng
> > Cc: Zhao Yakui
> > Reviewed-by: Huang Ying
> > ---
> > drivers/acpi/acpi_ipmi.c | 249
> > +++---
> > 1 file changed, 149 insertions(+), 100 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c index
> > 527ee43..cbf25e0 100644
> > --- a/drivers/acpi/acpi_ipmi.c
> > +++ b/drivers/acpi/acpi_ipmi.c
> > @@ -1,8 +1,9 @@
> > /*
> > * acpi_ipmi.c - ACPI IPMI opregion
> > *
> > - * Copyright (C) 2010 Intel Corporation
> > - * Copyright (C) 2010 Zhao Yakui
> > + * Copyright (C) 2010, 2013 Intel Corporation
> > + *Author: Zhao Yakui
> > + *Lv Zheng
> > *
> > *
>
> ~~
> > *
> > @@ -67,6 +68,7 @@ struct acpi_ipmi_device {
> > long curr_msgid;
> > unsigned long flags;
> > struct ipmi_smi_info smi_data;
> > + atomic_t refcnt;
>
> Can you use a kref instead?
Please see my concerns in another email.
>
> > };
> >
> > struct ipmi_driver_data {
> > @@ -107,8 +109,8 @@ struct acpi_ipmi_buffer { static void
> > ipmi_register_bmc(int iface, struct device *dev); static void
> > ipmi_bmc_gone(int iface); static void ipmi_msg_handler(struct
> > ipmi_recv_msg *msg, void *user_msg_data); -static void
> > acpi_add_ipmi_device(struct acpi_ipmi_device *ipmi_device); -static
> > void acpi_remove_ipmi_device(struct acpi_ipmi_device *ipmi_device);
> > +static int ipmi_install_space_handler(struct acpi_ipmi_device *ipmi);
> > +static void ipmi_remove_space_handler(struct acpi_ipmi_device *ipmi);
> >
> > static struct ipmi_driver_data driver_data = {
> > .ipmi_devices = LIST_HEAD_INIT(driver_data.ipmi_devices),
> > @@ -122,6 +124,80 @@ static struct ipmi_driver_data driver_data = {
> > },
> > };
> >
> > +static struct acpi_ipmi_device *
> > +ipmi_dev_alloc(int iface, struct ipmi_smi_info *smi_data, acpi_handle
> > +handle) {
> > + struct acpi_ipmi_device *ipmi_device;
> > + int err;
> > + ipmi_user_t user;
> > +
> > + ipmi_device = kzalloc(sizeof(*ipmi_device), GFP_KERNEL);
> > + if (!ipmi_device)
> > + return NULL;
> > +
> > + atomic_set(_device->refcnt, 1);
> > + INIT_LIST_HEAD(_device->head);
> > + INIT_LIST_HEAD(_device->tx_msg_list);
> > + spin_lock_init(_device->tx_msg_lock);
> > +
> > + ipmi_device->handle = handle;
> > + ipmi_device->pnp_dev = to_pnp_dev(get_device(smi_data->dev));
> > +
Re: [PATCH, re-send] Always trap on BUG()
On 07/26/2013 06:05 AM, Ingo Molnar wrote: > * Chen Gang wrote: > >> On 07/23/2013 05:36 PM, Ingo Molnar wrote: >>> >>> (the crazies can keep a separate patch to remove even more of BUG() to win >>> a K or two.) >>> >> >> Excuse me, my English is not quite well, I do not quite understand your >> meaning, could you please repeat again in details or say more clearly ? > > I meant: those people who'd like to have the tiny > additional space savings offered by !CONFIG_BUG (and are > crazy enough to live with non-determinism in exchange for a > measly payment of 1 KB), can apply a separate, out of tree > patch just fine and don't need upstream kernel support. > Thank you for your reply in details. Thanks -- Chen Gang -- 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] kernel/irq/devres.c: move "kernel/irq/devres.c" to "drivers/base/devres_irq.c"
In the other mail thread, the related maintainer for s390 said: "s390 will have GENERIC_HARDIRQS soon (very likely next merge window)" For efficiency reason, I should stop trying this issue any more. I found this issue by building s390 with allmodconfig, but s390 will be OK for this issue soon. If no direct cause, it is not a good idea to spend members expensive time resources only for one discussing. Thanks. On 07/24/2013 09:59 AM, Chen Gang wrote: > On 07/23/2013 11:31 PM, Greg KH wrote: >> On Tue, Jul 23, 2013 at 03:36:04PM +0800, Chen Gang wrote: >>> "kernel/irq/devres.c" is a driver extension tool for irq (with devres) >>> which is independent on 'GENERIC_HARDIRQS', so it is not suitable to >>> still be in "kernel/irq/" which depends on 'GENERIC_HARDIRQS'. >>> >>> It is a basic tool for drivers, so can move it to "drivers/base/" to be >>> independent on 'GENERIC_HARDIRQS'. >>> >>> It is about irq features, so if can not find other more suitable place, >>> can still let their declaration in "include/linux/interrupts.h". >>> >>> The related error (with randconfig which disable 'GENERIC_HARDIRQS') >>> >>> drivers/built-in.o: In function `dw_dma_probe': >>> (.text+0x3747a): undefined reference to `devm_request_threaded_irq' >> >> Don't fix problems when you are moving files around, that makes it >> _very_ hard to review. >> > > OK, thanks, I should notice next time (originally, I really did not know > about it). > > Hmm... but for our case, if move the related file, it also can solve the > related issue, it is only one action. > >> Remember, one thing per patch please. >> > > OK, thanks, I will try (that may let me make more patches, which is not > bad for myself ;-)). > > >>> Signed-off-by: Chen Gang >>> --- >>> drivers/base/Makefile |2 +- >>> drivers/base/devres_irq.c | 94 >>> + >>> kernel/irq/Makefile |2 +- >>> kernel/irq/devres.c | 94 >>> - >>> 4 files changed, 96 insertions(+), 96 deletions(-) >>> create mode 100644 drivers/base/devres_irq.c >>> delete mode 100644 kernel/irq/devres.c >> >> Please use git when renaming files so that the move is shown in the git >> patch. As it is, I would have to verify this by hand, and I don't want >> to ever have to do that. >> > > Oh, thanks, I need use git to perform it (I should try to familiar with > git). > >> Also, I have no problem with the file being where it is. This is for >> irqs, which are handled by the interrupt maintainers, no need to put it >> in the driver core, just because it happens to deal with "resources". >> We arrange things for ease of maintainability, not always logically :) >> > > Hmm... normally, 'maintainability' has no conflict with 'logically', if > we feel they are conflict, that means both of them need improvement. > > For 'logically', is it suitable to move "resources" from "drivers/base" > to "lib/", since they are already not only for drivers wide, but also > for kernel wide ? (especially, some of "devm*" have already been in "lib/"). > > For 'maintainability', is it suitable to let "kernel/irq" independent on > 'GENERIC_HARDIRQS' or "mv kernel/irq/devres.c kernel/devres_irq.c" ? > > :-) > > Thanks. > -- Chen Gang -- 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: Ugly patches for stolen reservation
On 07/25/2013 04:17 PM, Jesse Barnes wrote: > Well, it's ok if the boot loader writes to this memory, the worst > that'll happen is you'll see garbage on the screen. If the boot loader > tries to do MMIO mapping on top it'll get into trouble... but why would > it do that? > > Jesse Much worse: it could be hunting for a place to put the kernel, and put it there. -hpa -- 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 06/13] ACPI/IPMI: Add reference counting for ACPI operation region handlers
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, July 26, 2013 4:27 AM
>
> On Tuesday, July 23, 2013 04:09:43 PM Lv Zheng wrote:
> > This patch adds reference couting for ACPI operation region handlers
> > to fix races caused by the ACPICA address space callback invocations.
> >
> > ACPICA address space callback invocation is not suitable for Linux
> > CONFIG_MODULE=y execution environment. This patch tries to protect
> > the address space callbacks by invoking them under a module safe
> environment.
> > The IPMI address space handler is also upgraded in this patch.
> > The acpi_unregister_region() is designed to meet the following
> > requirements:
> > 1. It acts as a barrier for operation region callbacks - no callback will
> >happen after acpi_unregister_region().
> > 2. acpi_unregister_region() is safe to be called in moudle->exit()
> >functions.
> > Using reference counting rather than module referencing allows such
> > benefits to be achieved even when acpi_unregister_region() is called
> > in the environments other than module->exit().
> > The header file of include/acpi/acpi_bus.h should contain the
> > declarations that have references to some ACPICA defined types.
> >
> > Signed-off-by: Lv Zheng
> > Reviewed-by: Huang Ying
> > ---
> > drivers/acpi/acpi_ipmi.c | 16 ++--
> > drivers/acpi/osl.c | 224
> ++
> > include/acpi/acpi_bus.h |5 ++
> > 3 files changed, 235 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c index
> > 5f8f495..2a09156 100644
> > --- a/drivers/acpi/acpi_ipmi.c
> > +++ b/drivers/acpi/acpi_ipmi.c
> > @@ -539,20 +539,18 @@ out_ref:
> > static int __init acpi_ipmi_init(void) {
> > int result = 0;
> > - acpi_status status;
> >
> > if (acpi_disabled)
> > return result;
> >
> > mutex_init(_data.ipmi_lock);
> >
> > - status = acpi_install_address_space_handler(ACPI_ROOT_OBJECT,
> > - ACPI_ADR_SPACE_IPMI,
> > - _ipmi_space_handler,
> > - NULL, NULL);
> > - if (ACPI_FAILURE(status)) {
> > + result = acpi_register_region(ACPI_ADR_SPACE_IPMI,
> > + _ipmi_space_handler,
> > + NULL, NULL);
> > + if (result) {
> > pr_warn("Can't register IPMI opregion space handle\n");
> > - return -EINVAL;
> > + return result;
> > }
> >
> > result = ipmi_smi_watcher_register(_data.bmc_events);
> > @@ -596,9 +594,7 @@ static void __exit acpi_ipmi_exit(void)
> > }
> > mutex_unlock(_data.ipmi_lock);
> >
> > - acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
> > - ACPI_ADR_SPACE_IPMI,
> > - _ipmi_space_handler);
> > + acpi_unregister_region(ACPI_ADR_SPACE_IPMI);
> > }
> >
> > module_init(acpi_ipmi_init);
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index
> > 6ab2c35..8398e51 100644
> > --- a/drivers/acpi/osl.c
> > +++ b/drivers/acpi/osl.c
> > @@ -86,6 +86,42 @@ static struct workqueue_struct *kacpid_wq; static
> > struct workqueue_struct *kacpi_notify_wq; static struct
> > workqueue_struct *kacpi_hotplug_wq;
> >
> > +struct acpi_region {
> > + unsigned long flags;
> > +#define ACPI_REGION_DEFAULT0x01
> > +#define ACPI_REGION_INSTALLED 0x02
> > +#define ACPI_REGION_REGISTERED 0x04
> > +#define ACPI_REGION_UNREGISTERING 0x08
> > +#define ACPI_REGION_INSTALLING 0x10
>
> What about (1UL << 1), (1UL << 2) etc.?
>
> Also please remove the #defines out of the struct definition.
OK.
>
> > + /*
> > +* NOTE: Upgrading All Region Handlers
> > +* This flag is only used during the period where not all of the
> > +* region handers are upgraded to the new interfaces.
> > +*/
> > +#define ACPI_REGION_MANAGED0x80
> > + acpi_adr_space_handler handler;
> > + acpi_adr_space_setup setup;
> > + void *context;
> > + /* Invoking references */
> > + atomic_t refcnt;
>
> Actually, why don't you use krefs?
If you take a look at other piece of my codes, you'll find there are two
reasons:
1. I'm using while (atomic_read() > 1) to implement the objects' flushing and
there is no kref API to do so.
I just think it is not suitable for me to introduce such an API into kref.h
and start another argument around kref designs in this bug fix patch. :-)
I'll start a discussion about kref design using another thread.
2. I'm using ipmi_dev|msg_release() as a pair of ipmi_dev|msg_alloc(), it's
kind of atomic_t coding style.
If atomic_t is changed to struct kref, I will need to implement two API,
__ipmi_dev_release() to take a struct kref as parameter and call
ipmi_dev_release inside it.
By not using kref, I needn't
Re: Ugly patches for stolen reservation
On 07/25/2013 05:31 PM, Linus Torvalds wrote: > On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote: >> So the bootloader is just as likely to step on things... what happens >> when/if it does? > > This isn't a new problem. We've had this "firmware tables don't show > all devices" issue before. > Yes, I just want to know what happens. > The only odd thing about this one is how the quirk in question uses > "e820_add_region()" instead of just adding things to the MMIO list. > And I think that's actually likely a mistake. > > So Jesse, why don't you do what the other quirks do, and claim an > actual MMIO resource? If you make it a real resource, you'll get to > use fancy things like REAL NAMES, and actually document it. With > human-readable strings. > > See quirk_io_region() in drivers/pci/quirks.c for example. The same > code except for IORESOURCE_MEM should do a lovely job.. > > And even *if* it's already marked reserved in the e820 table, it just > looks nice in /proc/iomem. We should do both -- mark it reserved in early boot, and add it as an MMIO region later during boot. The problem here, if I'm reading this right, is that this memory region is marked as normal RAM in e820, which is much worse than just not marking it as reserved; we need to intercept this memory before we genuinely turn it into normal RAM. At the same time, we have no protection against the bootloader using this as memory or even placing the kernel there. The BIOS needs to be fixed regardless of what workarounds we do in the kernel. -hpa -- 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 03/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI transfers
On 07/25/2013 07:16 PM, Zheng, Lv wrote: If I understand this correctly, the problem would be if: rem_time = wait_for_completion_timeout(_msg->tx_complete, IPMI_TIMEOUT); returns on a timeout, then checks msg_done and races with something setting msg_done. If that is the case, you would need the smp_rmb() before checking msg_done. However, the timeout above is unnecessary. You are using ipmi_request_settime(), so you can set the timeout when the IPMI command fails and returns a failure message. The driver guarantees a return message for each request. Just remove the timeout from the completion, set the timeout and retries in the ipmi request, and the completion should handle the barrier issues. It's just difficult for me to determine retry count and timeout value, maybe retry=0, timeout=IPMI_TIMEOUT is OK. The code of the timeout completion is already there, I think the quick fix code should not introduce this logic. I'll add a new patch to apply your comment. Since it is a local BMC, I doubt a retry is required. That is probably fine. Or you could set retry=1 and timeout=IPMI_TIMEOUT/2 if you wanted to be more sure, but I doubt it would make a difference. The only time you really need to worry about retries is if you are resetting the BMC or it is being overloaded. Plus, from a quick glance at the code, it doesn't look like it will properly handle a situation where the timeout occurs and is handled then the response comes in later. PATCH 07 fixed this issue. Here we just need the smp_rmb() or holding tx_msg_lock() around the acpi_format_ipmi_response(). If you apply the fix like I suggest, then the race goes away. If there's no timeout and it just waits for the completion, things get a lot simpler. Thanks for commenting. No problem, thanks for working on this. -corey -- 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] ARM: SoC fixes for 3.11-rc
Hi Linus, The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b: Linux 3.11-rc2 (2013-07-21 12:05:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to 515c0967205f2e6d0ca1602ce0de65f9aec1d215: mfd: max8925: fix dt code for backlight (2013-07-25 16:57:00 -0700) ARM: SoC fixes for 3.11-rc This is a largeish batch of fixes, mostly because I missed -rc2 due to travel/vacation. So in number these are a bit more than ideal unless you amortize them over two -rcs. Quick breakdown: - Defconfig updates - Making multi_v7_defconfig useful on more hardware to encourage single-image usage - Davinci and nomadik updates due to new code merged this merge window - Fixes for UART on Samsung platforms, both PM and clock-related - A handful of warning fixes from defconfig builds, including for max8925 backlight and pxamci (both with appropriate acks) - Exynos5440 fixes for LPAE configuration, PM - ...plus a bunch of other smaller changes all over the place I expect to switch to regressions-or-severe-bugs-only fixes from here on out. Alexander Shiyan (1): ARM: i.MX27: Typo fix Amit Daniel Kachhap (1): ARM: SAMSUNG: Add SAMSUNG_PM config option to select pm Arnd Bergmann (1): ARM: pxa: propagate errors from regulator_enable() to pxamci Fabio Estevam (2): ARM: dts: imx51-babbage: Pass a real clock to the codec ARM: multi_v7_defconfig: Select USB chipidea driver Guennadi Liakhovetski (1): dmaengine: shdma: fix a build failure on platforms with no DMA support Kukjin Kim (1): ARM: EXYNOS: skip pm support on exynos5440 Laurent Pinchart (1): ARM i.MX53: mba53: Fix PWM backlight DT node Linus Walleij (2): ARM: nomadik: update defconfig base ARM: nomadik: configure for NO_HZ and HRTIMERS Liu Ying (1): ARM: i.MX6Q: correct emi_sel clock muxing Markus Pargmann (1): ARM: imx27: Fix documentation for SPLL clock Mike Frysinger (1): ARM: footbridge: fix overlapping PCI mappings Olof Johansson (7): Merge tag 'davinci-fixes-for-v3.11-rc2' of git://git.kernel.org/.../nsekhar/linux-davinci into fixes Merge tag 'omap-for-v3.11/fixes-against-rc1' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'imx-fixes-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes Merge tag 'nomadik-defconfig-for-arm-soc' of git://git.kernel.org/.../linusw/linux-nomadik into fixes ARM: omap5: Only select errata 798181 if SMP Merge tag 'samsung-fixes-1' of git://git.kernel.org/.../kgene/linux-samsung into fixes mfd: max8925: fix dt code for backlight Philipp Zabel (2): ARM i.MX53: Fix UART pad configuration ARM i.MX6Q: Fix IOMUXC GPR1 defines for ENET_CLK_SEL and IPU1/2_MUX Rob Herring (1): ARM: highbank: Only touch common coherency control register fields Roger Quadros (1): ARM: OMAP2+: Provide alias to USB PHY clock Sachin Kamat (1): ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos Sekhar Nori (2): ARM: davinci: make file local variables static ARM: davinci: defconfig: enable EDMA driver Shawn Guo (2): ARM: mxs: saif0 is the clock provider to sgtl5000 ARM: imx: fix vf610 enet module clock selection Srinivas Kandagatla (2): ARM: dts: STi: Fix pinconf setup for STiH416 serial2 ARM: STi: Set correct ARM ERRATAs. Subash Patel (1): ARM: EXYNOS: change the PHYSMEM_BITS and SECTION_SIZE Sylwester Nawrocki (1): ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART Thomas Abraham (1): ARM: EXYNOS: Enable 64-bit DMA for EXYNOS5440 if LPAE is enabled Tony Lindgren (3): ARM: multi_v7: Enabled omap4430 sdp nfsroot ARM: dts: Add missing vmmc2 regulator for twl Merge branch 'omap-for-v3.11/dt-fixes' into omap-for-v3.11/fixes Ulf Hansson (1): ARM: nomadik: Update MMC defconfigs Vincent Stehlé (2): ARM: keystone: fix compilation warning ARM: zynq: fix compilation warning Wei Yongjun (1): ARM: edma: remove duplicated include from edma.c Yadwinder Singh Brar (2): ARM: SAMSUNG: Save/restore only selected uart's registers ARM: EXYNOS: Fix low level debug support .../devicetree/bindings/clock/imx27-clock.txt | 1 + arch/arm/Kconfig | 3 +- arch/arm/boot/dts/imx28-apx4devkit.dts | 2 +- arch/arm/boot/dts/imx28-evk.dts| 2 +- arch/arm/boot/dts/imx28-m28evk.dts | 2 +- arch/arm/boot/dts/imx28.dtsi | 1 + arch/arm/boot/dts/imx51-babbage.dts| 13 +- arch/arm/boot/dts/imx53-mba53.dts | 2 +- arch/arm/boot/dts/imx53.dtsi
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On 07/25/2013 01:16 PM, Rob Herring wrote: > On Thu, Jul 25, 2013 at 2:31 PM, Jason Cooper wrote: >> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote: >>> On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson wrote: >> One problem that needs to be solved is obviously how a binding graduates from tentative to locked. This work isn't going to be very interesting to most people, I suspect. Think standards committee type work. >>> >>> I think a time based stabilization period would be better than a >>> separate directory to apply bindings too. Or time plus periodic review >>> perhaps. >> >> The only problem with a time-based versus separate directory is how do >> users who've downloaded the tree determine which bindings are stable? >> If they pull a tarball, or receive an SDK, there is most likely no git >> history attached. > > Well, if time based includes moving the binding out of the kernel, > then that is what defines it as stable or not. I guess that is a form > of a separate directory. I don't think we want to be moving bindings > twice: tentative -> stable and kernel -> DT repo. > > The policy could be as simple as an binding without change in at least > N kernel releases is moved out and stable. That might not be quite the right criteria. Just because something didn't change doesn't mean it's "correct" and that any problems in the binding have been addressed. As one example, on Tegra, we have a few bindings that haven't changed in a while, yet rely on custom properties for describing which DMA channel to use, rather than using the fairly-recently-introduced standard DMA DT properties (this particular example is being rectified now, but I'm sure there are plenty of similar examples) -- 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/
[PULL REQUEST] 2 more bug fixes for md in 3.11
The following changes since commit 30bc9b53878a9921b02e3b5bc4283ac1c6de102a: md/raid1: fix bio handling problems in process_checks() (2013-07-18 14:18:04 +1000) are available in the git repository at: git://neil.brown.name/md tags/md/3.11-fixes for you to fetch changes up to f94c0b6658c7edea8bc19d13be321e3860a3fa54: md/raid5: fix interaction of 'replace' and 'recovery'. (2013-07-25 16:46:57 +1000) 2 more bugfixes for md in 3.11 Both marked for -stable, both since 3.3. I guess I should spend more time testing... NeilBrown (2): md/raid10: remove use-after-free bug. md/raid5: fix interaction of 'replace' and 'recovery'. drivers/md/raid10.c | 8 +++- drivers/md/raid5.c | 15 ++- drivers/md/raid5.h | 1 + 3 files changed, 18 insertions(+), 6 deletions(-) signature.asc Description: PGP signature
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On 07/25/2013 02:53 PM, Ben Hutchings wrote:
> On Thu, Jul 25, 2013 at 04:32:28PM -0400, Jason Cooper wrote:
> [...]
>> One of the things I've been trying to square up in my head is how to
>> retain the history of the binding when moving to the new tree. My
>> current idea was to clone the kernel tree, add one patch deleting
>> everything but the bindings and dts files, and one more patch moving
>> things where we want them (arch/{powerpc,arm}/boot/dts -> dts).
>>
>> Then, as needed, we could merge a kernel version tag and delete
>> everything we don't need (code) in the merge commit.
>>
>> The downside of this is it would be messy, the upside is that we could
>> closely track the kernel tree (until the bindings and dts are moved
>> out), and retain the history of the bindings and dts files.
> [...]
>
> It's *extremely* messy, but 'git filter-branch' might help to make a
> clean tracking branch preserving history of just DT files. David
> Woodhouse did something like that for the linux-firmware repo
> initially.
Ian Campbell is already working on exactly this solution:
https://lkml.org/lkml/2013/7/23/547
--
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.10.1: echo repair > sync_action causes hang on RAID-1 (2 x SSD)
On Thu, 25 Jul 2013 19:10:50 -0400 "Justin Piszcz" wrote: > > > -Original Message- > From: NeilBrown [mailto:ne...@suse.de] > Sent: Sunday, July 21, 2013 7:03 PM > To: Justin Piszcz > Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org > Subject: Re: 3.10.1: echo repair > sync_action causes hang on RAID-1 (2 x > SSD) > > > Hi Justin, > > this is a known bug. Fix has been accepted into mainline for 3.11-rc2. > > Hopefully it will get into 3.10.3 (too late for 3.10.2). > > > NeilBrown > > > Hi Neil, > > Did the fix by chance make it into 3.10.3? No, it looks like it missed again. I gather there was a large inflow of patches for -stable in the 3.11-rc1 merge window and Greg has been processing them in batches. Hopefully in 3.10.4. The relevant patch is commit 30bc9b53878a9921b02e3 in mainline. NeilBrown > > The same issue occurs with 3.10.3 for me as well: > > Every 1.0s: cat /proc/mdstatThu Jul 25 19:09:46 > 2013 > > Personalities : [raid1] > md1 : active raid1 sdc2[0] sdb2[1] > 233381376 blocks [2/2] [UU] > [>] resync = 0.0% (151488/233381376) > finish=32045.3m > in speed=121K/sec > > md0 : active raid1 sdc1[0] sdb1[1] > 1048512 blocks [2/2] [UU] > > unused devices: > > > > Justin. signature.asc Description: PGP signature
Re: Ugly patches for stolen reservation
On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote: > So the bootloader is just as likely to step on things... what happens when/if > it does? This isn't a new problem. We've had this "firmware tables don't show all devices" issue before. The only odd thing about this one is how the quirk in question uses "e820_add_region()" instead of just adding things to the MMIO list. And I think that's actually likely a mistake. So Jesse, why don't you do what the other quirks do, and claim an actual MMIO resource? If you make it a real resource, you'll get to use fancy things like REAL NAMES, and actually document it. With human-readable strings. See quirk_io_region() in drivers/pci/quirks.c for example. The same code except for IORESOURCE_MEM should do a lovely job.. And even *if* it's already marked reserved in the e820 table, it just looks nice in /proc/iomem. Hmm? Linus -- 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: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Thu, Jul 25, 2013 at 7:18 PM, Russell King - ARM Linux wrote: > On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote: >> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote: >> > On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson wrote: >> >> > > One problem that needs to be solved is obviously how a binding >> > > graduates from tentative to locked. This work isn't going to be very >> > > interesting to most people, I suspect. Think standards committee type >> > > work. >> > >> > I think a time based stabilization period would be better than a >> > separate directory to apply bindings too. Or time plus periodic review >> > perhaps. >> >> The only problem with a time-based versus separate directory is how do >> users who've downloaded the tree determine which bindings are stable? >> If they pull a tarball, or receive an SDK, there is most likely no git >> history attached. >> >> I think the idea of a 'tentative' directory (or 'locked') is churnish, >> but necessary. If I DL'd a tarball and had to type 'tentative' to get >> to the binding doc I wanted, that would be a pretty clear clue to be >> delicate about how I trust/use/plan with that binding. > > It's actually extremely simple. If the bindings are in development, > they must not appear in a -final released kernel. Anything that appears > in a -final kernel becomes part of the ABI at that point. > > That obviously does not mean you remove them in the last -rc and put > them back during the merge window! > > That's how we handle every other ABI thing in the kernel tree, why should > DT files be any different? (I've added Linus and Grant to this discussion.) > > As I've already stated, it is intended to eventually remove the DT files > from the kernel tree and have them as a separately maintained project, > which means they will be independent of the kernel version. > -- > 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/ Having a schema system for the device trees is closely related to this discussion. In this case the schema would probably be equal to the stable set of nodes. This has been discussed before on the device tree mailing list. The dtc compiler would take this schema and validate the trees it compiles against it issuing warnings for 'non-standard' usage. Over time the schema would be updated to allow these usages when everyone agrees to it. Note that there would be a single schema describing all possible legal Linux device trees. The scheme is also quite useful for new tree developers since it will show them the universe of device tree attributes that have already been standardized. By using comments, you could probably turn the device tree documentation into the schema source files. -- Jon Smirl jonsm...@gmail.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: [PATCH 03/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI transfers
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Friday, July 26, 2013 3:33 AM
>
> On Thursday, July 25, 2013 01:12:38 PM Corey Minyard wrote:
> > On 07/25/2013 07:06 AM, Rafael J. Wysocki wrote:
> > > On Thursday, July 25, 2013 03:09:35 AM Zheng, Lv wrote:
> > >> -stable according to the previous conversation.
> > >>
> > >>> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> > >>> Sent: Thursday, July 25, 2013 7:38 AM
> > >>>
> > >>> On Tuesday, July 23, 2013 04:09:15 PM Lv Zheng wrote:
> > This patch fixes races caused by unprotected ACPI IPMI transfers.
> >
> > We can see the following crashes may occur:
> > 1. There is no tx_msg_lock held for iterating tx_msg_list in
> > ipmi_flush_tx_msg() while it is parellel unlinked on failure in
> > acpi_ipmi_space_handler() under protection of tx_msg_lock.
> > 2. There is no lock held for freeing tx_msg in
> > acpi_ipmi_space_handler()
> > while it is parellel accessed in ipmi_flush_tx_msg() and
> > ipmi_msg_handler().
> >
> > This patch enhances tx_msg_lock to protect all tx_msg accesses to
> > solve this issue. Then tx_msg_lock is always held around
> > complete() and tx_msg accesses.
> > Calling smp_wmb() before setting msg_done flag so that messages
> > completed due to flushing will not be handled as 'done' messages
> > while their contents are not vaild.
> >
> > Signed-off-by: Lv Zheng
> > Cc: Zhao Yakui
> > Reviewed-by: Huang Ying
> > ---
> > drivers/acpi/acpi_ipmi.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
> > index
> > b37c189..527ee43 100644
> > --- a/drivers/acpi/acpi_ipmi.c
> > +++ b/drivers/acpi/acpi_ipmi.c
> > @@ -230,11 +230,14 @@ static void ipmi_flush_tx_msg(struct
> > >>> acpi_ipmi_device *ipmi)
> > struct acpi_ipmi_msg *tx_msg, *temp;
> > int count = HZ / 10;
> > struct pnp_dev *pnp_dev = ipmi->pnp_dev;
> > + unsigned long flags;
> >
> > + spin_lock_irqsave(>tx_msg_lock, flags);
> > list_for_each_entry_safe(tx_msg, temp, >tx_msg_list,
> head) {
> > /* wake up the sleep thread on the Tx msg */
> > complete(_msg->tx_complete);
> > }
> > + spin_unlock_irqrestore(>tx_msg_lock, flags);
> >
> > /* wait for about 100ms to flush the tx message list */
> > while (count--) {
> > @@ -268,13 +271,12 @@ static void ipmi_msg_handler(struct
> > >>> ipmi_recv_msg *msg, void *user_msg_data)
> > break;
> > }
> > }
> > - spin_unlock_irqrestore(_device->tx_msg_lock, flags);
> >
> > if (!msg_found) {
> > dev_warn(_dev->dev,
> > "Unexpected response (msg id %ld) is
> > returned.\n",
> > msg->msgid);
> > - goto out_msg;
> > + goto out_lock;
> > }
> >
> > /* copy the response data to Rx_data buffer */ @@ -286,10
> > +288,14 @@ static void ipmi_msg_handler(struct ipmi_recv_msg
> > *msg, void
> > >>> *user_msg_data)
> > }
> > tx_msg->rx_len = msg->msg.data_len;
> > memcpy(tx_msg->data, msg->msg.data, tx_msg->rx_len);
> > + /* tx_msg content must be valid before setting msg_done flag */
> > + smp_wmb();
> > >>> That's suspicious.
> > >>>
> > >>> If you need the write barrier here, you'll most likely need a read
> > >>> barrier somewhere else. Where's that?
> > >> It might depend on whether the content written before the smp_wmb() is
> used or not by the other side codes under the condition set after the
> smp_wmb().
> > >>
> > >> So comment could be treated as 2 parts:
> > >> 1. do we need a paired smp_rmb().
> > >> 2. do we need a smp_wmb().
> > >>
> > >> For 1.
> > >> If we want a paired smp_rmb(), then it will appear in this function:
> > >>
> > >> 186 static void acpi_format_ipmi_response(struct acpi_ipmi_msg *msg,
> > >> 187 acpi_integer *value, int rem_time)
> > >> 188 {
> > >> 189 struct acpi_ipmi_buffer *buffer;
> > >> 190
> > >> 191 /*
> > >> 192 * value is also used as output parameter. It represents the
> response
> > >> 193 * IPMI message returned by IPMI command.
> > >> 194 */
> > >> 195 buffer = (struct acpi_ipmi_buffer *)value;
> > >> 196 if (!rem_time && !msg->msg_done) {
> > >> 197 buffer->status = ACPI_IPMI_TIMEOUT;
> > >> 198 return;
> > >> 199 }
> > >> 200 /*
> > >> 201 * If the flag of msg_done is not set or
Re: [PATCH -v3 3/3] PCI,pciehp: use PCIe DSN to identify device change during suspend
On Fri, Jul 12, 2013 at 3:32 AM, Yijing Wang wrote:
> If device was removed from slot and reinsert a new device during
> suspend, pciehp can not identify the physical device change now.
> So the old driver .resume() method will be called for the new device,
> this is bad. If device support device serial number capability,
> we can identify this by DSN. So the reasonable way is first remove
> the old device, then enable the new device.
>
> Signed-off-by: Yijing Wang
> Cc: Paul Bolle
> Cc: "Rafael J. Wysocki"
> Cc: Oliver Neukum
> Cc: Gu Zheng
> Cc: linux-...@vger.kernel.org
> ---
> drivers/pci/hotplug/pciehp_core.c | 45
> +
> 1 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pciehp_core.c
> b/drivers/pci/hotplug/pciehp_core.c
> index 7fe9dbd..bc47f8e 100644
> --- a/drivers/pci/hotplug/pciehp_core.c
> +++ b/drivers/pci/hotplug/pciehp_core.c
> @@ -296,11 +296,38 @@ static int pciehp_suspend (struct pcie_device *dev)
> return 0;
> }
>
> +/*
> + * check the func 0 device serial number is changed,
> + * if device does not support device serial number,
> + * return false.
> + */
> +static bool device_serial_number_changed(struct pci_bus *pbus)
> +{
> + u64 old_dsn, new_dsn;
> + struct pci_dev *pdev;
> +
> + pdev = pci_get_slot(pbus, PCI_DEVFN(0, 0));
> + if (!pdev)
> + return false;
> +
> + old_dsn = pdev->sn;
> +
> + /* get func 0 device serial number */
> + new_dsn = pci_device_serial_number(pdev);
> + pci_dev_put(pdev);
> +
> + if (old_dsn != new_dsn)
> + return true;
> +
> + return false;
> +}
> +
> static int pciehp_resume (struct pcie_device *dev)
> {
> struct controller *ctrl;
> struct slot *slot;
> struct pci_bus *pbus = dev->port->subordinate;
> + int retval = 0;
> u8 status;
>
> ctrl = get_service_data(dev);
> @@ -315,6 +342,24 @@ static int pciehp_resume (struct pcie_device *dev)
> if (status) {
> if (list_empty(>devices))
> pciehp_enable_slot(slot);
> +
> + if (device_serial_number_changed(pbus)) {
> + /*
> +* first power off slot, avoid the old driver
> +* .remove() method touch the new hardware
> +*/
> + if (POWER_CTRL(ctrl)) {
> + retval = pciehp_power_off_slot(slot);
> + if (retval) {
> + ctrl_err(ctrl,
> + "Issue of Slot Disable
> command failed\n");
> + return 0;
> + }
> + msleep(1000);
> + pciehp_unconfigure_device(slot);
> + pciehp_enable_slot(slot);
> + }
> + }
I'm not sure this is implemented at the correct place. The idea of
using the serial number to detect card swaps is not really specific to
pciehp. I know the Device Serial Number capability is defined in the
PCIe spec, but it doesn't *require* any PCIe functionality, and
there's no reason a similar capability couldn't be defined for
conventional PCI.
I don't know much about it, but conventional PCI *does* in fact
support the VPD capability, which can contain a serial number. I
wonder if we should enhance pci_device_serial_number() to look for a
VPD serial number if there's no PCIe DSN. Then we would want this
check for card swap in a more generic place, e.g., somewhere in
pci_scan_slot(), so all forms of hotplug would benefit from it.
Also, I think it's possible to use acpiphp for ExpressCard slots, and
this patch doesn't help acpiphp detect card swaps. I don't see any
mention of suspend/resume in acpiphp, so I don't know if it does
anything at all to detect card changes while suspended. Maybe Rafael
can shed some light?
I put the first two patches on a pci/yijing-dsn-v3 branch while we
work out the details of this one.
Bjorn
> } else if (!list_empty(>devices)) {
> pciehp_disable_slot(slot);
> }
> --
> 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/
RE: [PATCH 03/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI transfers
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, July 26, 2013 2:13 AM
>
> On 07/25/2013 07:06 AM, Rafael J. Wysocki wrote:
> > On Thursday, July 25, 2013 03:09:35 AM Zheng, Lv wrote:
> >> -stable according to the previous conversation.
> >>
> >>> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> >>> Sent: Thursday, July 25, 2013 7:38 AM
> >>>
> >>> On Tuesday, July 23, 2013 04:09:15 PM Lv Zheng wrote:
> This patch fixes races caused by unprotected ACPI IPMI transfers.
>
> We can see the following crashes may occur:
> 1. There is no tx_msg_lock held for iterating tx_msg_list in
> ipmi_flush_tx_msg() while it is parellel unlinked on failure in
> acpi_ipmi_space_handler() under protection of tx_msg_lock.
> 2. There is no lock held for freeing tx_msg in acpi_ipmi_space_handler()
> while it is parellel accessed in ipmi_flush_tx_msg() and
> ipmi_msg_handler().
>
> This patch enhances tx_msg_lock to protect all tx_msg accesses to
> solve this issue. Then tx_msg_lock is always held around
> complete() and tx_msg accesses.
> Calling smp_wmb() before setting msg_done flag so that messages
> completed due to flushing will not be handled as 'done' messages
> while their contents are not vaild.
>
> Signed-off-by: Lv Zheng
> Cc: Zhao Yakui
> Reviewed-by: Huang Ying
> ---
> drivers/acpi/acpi_ipmi.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
> index
> b37c189..527ee43 100644
> --- a/drivers/acpi/acpi_ipmi.c
> +++ b/drivers/acpi/acpi_ipmi.c
> @@ -230,11 +230,14 @@ static void ipmi_flush_tx_msg(struct
> >>> acpi_ipmi_device *ipmi)
> struct acpi_ipmi_msg *tx_msg, *temp;
> int count = HZ / 10;
> struct pnp_dev *pnp_dev = ipmi->pnp_dev;
> +unsigned long flags;
>
> +spin_lock_irqsave(>tx_msg_lock, flags);
> list_for_each_entry_safe(tx_msg, temp, >tx_msg_list,
> head) {
> /* wake up the sleep thread on the Tx msg */
> complete(_msg->tx_complete);
> }
> +spin_unlock_irqrestore(>tx_msg_lock, flags);
>
> /* wait for about 100ms to flush the tx message list */
> while (count--) {
> @@ -268,13 +271,12 @@ static void ipmi_msg_handler(struct
> >>> ipmi_recv_msg *msg, void *user_msg_data)
> break;
> }
> }
> -spin_unlock_irqrestore(_device->tx_msg_lock, flags);
>
> if (!msg_found) {
> dev_warn(_dev->dev,
> "Unexpected response (msg id %ld) is
> returned.\n",
> msg->msgid);
> -goto out_msg;
> +goto out_lock;
> }
>
> /* copy the response data to Rx_data buffer */ @@ -286,10
> +288,14 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg,
> void
> >>> *user_msg_data)
> }
> tx_msg->rx_len = msg->msg.data_len;
> memcpy(tx_msg->data, msg->msg.data, tx_msg->rx_len);
> +/* tx_msg content must be valid before setting msg_done flag */
> +smp_wmb();
> >>> That's suspicious.
> >>>
> >>> If you need the write barrier here, you'll most likely need a read
> >>> barrier somewhere else. Where's that?
> >> It might depend on whether the content written before the smp_wmb() is
> used or not by the other side codes under the condition set after the
> smp_wmb().
> >>
> >> So comment could be treated as 2 parts:
> >> 1. do we need a paired smp_rmb().
> >> 2. do we need a smp_wmb().
> >>
> >> For 1.
> >> If we want a paired smp_rmb(), then it will appear in this function:
> >>
> >> 186 static void acpi_format_ipmi_response(struct acpi_ipmi_msg *msg,
> >> 187 acpi_integer *value, int rem_time)
> >> 188 {
> >> 189 struct acpi_ipmi_buffer *buffer;
> >> 190
> >> 191 /*
> >> 192 * value is also used as output parameter. It represents the
> response
> >> 193 * IPMI message returned by IPMI command.
> >> 194 */
> >> 195 buffer = (struct acpi_ipmi_buffer *)value;
> >> 196 if (!rem_time && !msg->msg_done) {
> >> 197 buffer->status = ACPI_IPMI_TIMEOUT;
> >> 198 return;
> >> 199 }
> >> 200 /*
> >> 201 * If the flag of msg_done is not set or the recv length is
> >> zero,
> it
> >> 202 * means that the IPMI command is not executed correctly.
> >> 203 * The status code will be ACPI_IPMI_UNKNOWN.
> >> 204 */
> >> 205 if (!msg->msg_done || !msg->rx_len) {
> >> 206
RE: [PATCH 03/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI transfers
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Thursday, July 25, 2013 8:07 PM
>
> On Thursday, July 25, 2013 03:09:35 AM Zheng, Lv wrote:
> > -stable according to the previous conversation.
> >
> > > From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> > > Sent: Thursday, July 25, 2013 7:38 AM
> > >
> > > On Tuesday, July 23, 2013 04:09:15 PM Lv Zheng wrote:
> > > > This patch fixes races caused by unprotected ACPI IPMI transfers.
> > > >
> > > > We can see the following crashes may occur:
> > > > 1. There is no tx_msg_lock held for iterating tx_msg_list in
> > > >ipmi_flush_tx_msg() while it is parellel unlinked on failure in
> > > >acpi_ipmi_space_handler() under protection of tx_msg_lock.
> > > > 2. There is no lock held for freeing tx_msg in acpi_ipmi_space_handler()
> > > >while it is parellel accessed in ipmi_flush_tx_msg() and
> > > >ipmi_msg_handler().
> > > >
> > > > This patch enhances tx_msg_lock to protect all tx_msg accesses to
> > > > solve this issue. Then tx_msg_lock is always held around
> > > > complete() and tx_msg accesses.
> > > > Calling smp_wmb() before setting msg_done flag so that messages
> > > > completed due to flushing will not be handled as 'done' messages
> > > > while their contents are not vaild.
> > > >
> > > > Signed-off-by: Lv Zheng
> > > > Cc: Zhao Yakui
> > > > Reviewed-by: Huang Ying
> > > > ---
> > > > drivers/acpi/acpi_ipmi.c | 10 --
> > > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
> > > > index
> > > > b37c189..527ee43 100644
> > > > --- a/drivers/acpi/acpi_ipmi.c
> > > > +++ b/drivers/acpi/acpi_ipmi.c
> > > > @@ -230,11 +230,14 @@ static void ipmi_flush_tx_msg(struct
> > > acpi_ipmi_device *ipmi)
> > > > struct acpi_ipmi_msg *tx_msg, *temp;
> > > > int count = HZ / 10;
> > > > struct pnp_dev *pnp_dev = ipmi->pnp_dev;
> > > > + unsigned long flags;
> > > >
> > > > + spin_lock_irqsave(>tx_msg_lock, flags);
> > > > list_for_each_entry_safe(tx_msg, temp, >tx_msg_list,
> > > > head) {
> > > > /* wake up the sleep thread on the Tx msg */
> > > > complete(_msg->tx_complete);
> > > > }
> > > > + spin_unlock_irqrestore(>tx_msg_lock, flags);
> > > >
> > > > /* wait for about 100ms to flush the tx message list */
> > > > while (count--) {
> > > > @@ -268,13 +271,12 @@ static void ipmi_msg_handler(struct
> > > ipmi_recv_msg *msg, void *user_msg_data)
> > > > break;
> > > > }
> > > > }
> > > > - spin_unlock_irqrestore(_device->tx_msg_lock, flags);
> > > >
> > > > if (!msg_found) {
> > > > dev_warn(_dev->dev,
> > > > "Unexpected response (msg id %ld) is
> > > > returned.\n",
> > > > msg->msgid);
> > > > - goto out_msg;
> > > > + goto out_lock;
> > > > }
> > > >
> > > > /* copy the response data to Rx_data buffer */ @@ -286,10
> > > > +288,14 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg,
> > > > void
> > > *user_msg_data)
> > > > }
> > > > tx_msg->rx_len = msg->msg.data_len;
> > > > memcpy(tx_msg->data, msg->msg.data, tx_msg->rx_len);
> > > > + /* tx_msg content must be valid before setting msg_done flag */
> > > > + smp_wmb();
> > >
> > > That's suspicious.
> > >
> > > If you need the write barrier here, you'll most likely need a read
> > > barrier somewhere else. Where's that?
> >
> > It might depend on whether the content written before the smp_wmb() is
> used or not by the other side codes under the condition set after the
> smp_wmb().
> >
> > So comment could be treated as 2 parts:
> > 1. do we need a paired smp_rmb().
> > 2. do we need a smp_wmb().
> >
> > For 1.
> > If we want a paired smp_rmb(), then it will appear in this function:
> >
> > 186 static void acpi_format_ipmi_response(struct acpi_ipmi_msg *msg,
> > 187 acpi_integer *value, int rem_time)
> > 188 {
> > 189 struct acpi_ipmi_buffer *buffer;
> > 190
> > 191 /*
> > 192 * value is also used as output parameter. It represents the
> response
> > 193 * IPMI message returned by IPMI command.
> > 194 */
> > 195 buffer = (struct acpi_ipmi_buffer *)value;
> > 196 if (!rem_time && !msg->msg_done) {
> > 197 buffer->status = ACPI_IPMI_TIMEOUT;
> > 198 return;
> > 199 }
> > 200 /*
> > 201 * If the flag of msg_done is not set or the recv length is
> > zero,
> it
> > 202 * means that the IPMI command is not executed correctly.
> > 203 * The status code will be ACPI_IPMI_UNKNOWN.
> > 204 */
> > 205 if (!msg->msg_done || !msg->rx_len) {
> > 206 buffer->status = ACPI_IPMI_UNKNOWN;
> > 207
Re: hpsa - BUG: using smp_processor_id() in preemptible [00000000 00000000] code: kworker/u:0/6
[Adding missing cc to linux-scsi] On Thu, 2013-07-25 at 23:33 +0200, John Kacur wrote: > Hi > > We're seeing this on a 3.6 kernel with the real-time patch applied, but it > looks like it is relevant with the real-time patch in the latest kernel > too. > > [ 49.688847] hpsa :03:00.0: hpsa0: <0x323a> at IRQ 67 using DAC > [ 49.749928] scsi0 : hpsa > [ 49.784437] BUG: using smp_processor_id() in preemptible [ > ] code: kworker/u:0/6 > [ 49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa] > [ 49.784468] Pid: 6, comm: kworker/u:0 Not tainted > 3.6.11.5-rt37.52.el6rt.x86_64.debug #1 > [ 49.784471] Call Trace: > [ 49.784512] [] debug_smp_processor_id+0x123/0x150 > [ 49.784520] [] enqueue_cmd_and_start_io+0x5a/0x100 > [hpsa] > [ 49.784529] [] > hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa] > [ 49.784537] [] ? swiotlb_dma_mapping_error+0x18/0x30 > [ 49.784544] [] ? swiotlb_dma_mapping_error+0x18/0x30 > [ 49.784553] [] > hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa] > [ 49.784562] [] > hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa] > [ 49.784571] [] > hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa] > [ 49.784580] [] hpsa_update_scsi_devices+0x11f/0x4f0 > [hpsa] > [ 49.784592] [] ? sub_preempt_count+0xa9/0xe0 > [ 49.784601] [] hpsa_scan_start+0xfd/0x150 [hpsa] > [ 49.784613] [] ? rt_spin_lock_slowunlock+0x78/0x90 > [ 49.784626] [] do_scsi_scan_host+0x37/0xa0 > [ 49.784632] [] do_scan_async+0x1a/0x30 > [ 49.784643] [] async_run_entry_fn+0x9b/0x1d0 > [ 49.784655] [] process_one_work+0x1f2/0x620 > [ 49.784661] [] ? process_one_work+0x180/0x620 > [ 49.784668] [] ? worker_thread+0x5e/0x3a0 > [ 49.784674] [] ? async_schedule+0x20/0x20 > [ 49.784681] [] worker_thread+0x133/0x3a0 > [ 49.784688] [] ? manage_workers+0x190/0x190 > [ 49.784696] [] kthread+0xa6/0xb0 > [ 49.784707] [] kernel_thread_helper+0x4/0x10 > [ 49.784715] [] ? finish_task_switch+0x8c/0x110 > [ 49.784721] [] ? _raw_spin_unlock_irq+0x3b/0x70 > [ 49.784727] [] ? retint_restore_args+0xe/0xe > [ 49.784734] [] ? kthreadd+0x1e0/0x1e0 > [ 49.784739] [] ? gs_change+0xb/0xb > > --- > > When I look at the code I see this call chain > enqueue_cmd_and_start_io()-> > set_performant_mode()-> > smp_processor_id() > Which if you have debugging enabled calls debug_processor_id() and > triggers the warning. > > I'm not very familiar with the hpsa code, so I'm not entirely sure what > the purpose of this line is > > c->Header.ReplyQueue = smp_processor_id() % h->nreply_queues; > > Is the purpose to simply try to get a range of ReplyQueue numbers, but > somewhat arbitrary? Or is it necessary that the current processor_id > is used? If it is the former, and you're not accessing per cpu structures, > or pinning a cpu, or anything like that then I would think it is safe to > change this to a raw_smp_processor_id() to get rid of a false positive > warning. > > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c > index 7f4f790..4e19267 100644 > --- a/drivers/scsi/hpsa.c > +++ b/drivers/scsi/hpsa.c > @@ -583,7 +583,7 @@ static void set_performant_mode(struct ctlr_info *h, > struct CommandList *c) > c->busaddr |= 1 | (h->blockFetchTable[c->Header.SGList] << 1); > if (likely(h->msix_vector)) > c->Header.ReplyQueue = > - smp_processor_id() % h->nreply_queues; > + raw_smp_processor_id() % h->nreply_queues; > } > } > > > Thanks > > John Kacur -- 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: [PATCHv2 3/3] fb: backlight: HX8357: Add HX8369 support
On Thursday, July 25, 2013 10:05 PM, Maxime Ripard wrote: > > From: Alexandre Belloni > > Add support for the Himax HX8369 controller as it is quite similar to the > hx8357. > > Signed-off-by: Alexandre Belloni > Signed-off-by: Maxime Ripard > Acked-by: Jingoo Han > --- > drivers/video/backlight/hx8357.c | 221 > --- > 1 file changed, 206 insertions(+), 15 deletions(-) > [] > + ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON); > + if (ret < 0) > + return ret; > + > + msleep(100); Hi Maxime Ripard, Could you add comment on this huge delay, too? Best regards, Jingoo Han -- 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] power: set PF_SUSPEND_TASK flag on tasks that call freeze_processes
On Thu, Jul 25, 2013 at 1:06 PM, Rafael J. Wysocki wrote: > > Can we spend an extra process flag on that? I suspect we can. But if somebody hollers later, we'll need to do some compaction.. Linus -- 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: [PATCHv2 2/3] video: hx8357: Make IM pins optional
On Thursday, July 25, 2013 10:05 PM, Maxime Ripard wrote:
>
> The IM pins of the HX8357 controller are used to define the interface
> used to feed pixel stream to the LCD panel.
>
> Most of the time, these pins are directly routed to either the ground or
> the VCC to set their values.
>
> Remove the need to assign GPIOs to these pins when we are in such a case.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/video/backlight/hx8357.c | 53
> +++-
> 1 file changed, 31 insertions(+), 22 deletions(-)
>
[.]
> + if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
> + lcd->use_im_pins = 1;
> +
> + for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
> + lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
> + "im-gpios", i);
> + if (lcd->im_pins[i] == -EPROBE_DEFER) {
> + dev_info(>dev, "GPIO requested is not here
> yet, deferring the
> probe\n");
> + return -EPROBE_DEFER;
> + }
> + if (!gpio_is_valid(lcd->im_pins[i])) {
> + dev_err(>dev, "Missing dt property:
> im-gpios\n");
> + return -EINVAL;
> + }
> +
> + ret = devm_gpio_request_one(>dev, lcd->im_pins[i],
> + GPIOF_OUT_INIT_LOW,
> + "im_pins");
> + if (ret) {
> + dev_err(>dev, "failed to request gpio %d:
> %d\n",
> + lcd->im_pins[i], ret);
> + return -EINVAL;
> + }
> }
> -
> - ret = devm_gpio_request_one(>dev, lcd->im_pins[i],
> - GPIOF_OUT_INIT_LOW, "im_pins");
> - if (ret) {
> - dev_err(>dev, "failed to request gpio %d: %d\n",
> - lcd->im_pins[i], ret);
> - return -EINVAL;
> - }
> - }
> + } else
> + lcd->use_im_pins = 0;
According to the 'Documentation/CodingStyle', braces are necessary as below.
} else {
lcd->use_im_pins = 0;
}
Others look good.
Acked-by: Jingoo Han
Best regards,
Jingoo Han
--
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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
Hi Willy, I understand completely. I don't blame you. Filter the thread. Done. I am not tired of the subject, quite the contrary. Please do not speak for me in that regard. After many years of wandering in the toxic wasteland, finally some actual progress. Regards, Daniel -- 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? debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
On Thu, Jul 25, 2013 at 10:04:23PM +0200, Oleg Nesterov wrote: > On 07/25, Oleg Nesterov wrote: > > > > To simplify the review, this is how it looks with the patch applied: > > v2. We can use simply use list_for_each_entry_safe() and > list_next_entry() should be calles under ->i_mutex. Although > debugfs_remove_recursive() can race with itself anyway, but > still. > > And the code looks much simpler. But I do not know what did > I miss. debugfs has a number of known issues with removing files / directories. Al has helpfully pointed them out to me, and it's on my list of things to fix, but it keeps getting pushed down by other things. Hopefully in a few weeks... Anyway, your changes below look good in this version, I don't see anything obviously wrong with it, but maybe others do? Care to turn this version into a patch I can test out? thanks, greg k-h -- 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] drivers: base: new memory config sysfs driver for large memory systems
On Thu, Jul 25, 2013 at 04:11:20PM -0500, Seth Jennings wrote: > +#define MEMFS_CLASS_NAME "memoryfs" One question, a "*fs" name in the kernel usually implies it is a separate filesystem, which this isn't at all, it's just a "normal" class/subsystem in the kernel. So how about "memory" instead? thanks, greg k-h -- 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] drivers: base: new memory config sysfs driver for large memory systems
On Thu, Jul 25, 2013 at 04:11:20PM -0500, Seth Jennings wrote: > From: Nathan Fontenot > > Large memory systems (1TB or more) experience boot delays on the order > of minutes due to the initializing the memory configuration part of > sysfs at /sys/devices/system/memory/. > > ppc64 has a memory block size of 256M and (I think) x86 is 128M. With 1TB > of RAM and a 256M block size, that's 4k memory blocks with 20 sysfs > entries per block that's around 80k items that need be created at boot > time in sysfs. Some systems go up to 16TB where the issue is > even more severe. > > This patch is a prototype for a new sysfs memory layout where the > entries are created on demand by writing memory block numbers into a > "show" and "hide" files to create and destroy the memory block > configuration attributes in sysfs. This would decouple the number of > sysfs entries created at boot time from the memory size, resulting in a > sysfs initialization time that doesn't increase and memory size > increase. > > Signed-off-by: Seth Jennings > Signed-off-by: Nathan Fontenot How does this tie into the patches Nathan sent yesterday for memory hotplug stuff that I thought modified the same part of the kernel? thanks, greg k-h -- 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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML
On Thu, Jul 25, 2013 at 10:51:21PM +, Daniel Phillips wrote: > On 07/25/2013 02:34 PM, Willy Tarreau wrote: > > Guys, could we please stop this endless boring thread ? > > Willy, I believe we are on the same side of the civility debate, but I > somehow got the feeling that you just characterized my comment re "open > and honest" as "endless and boring". > > I agree that the attempt to divert the intent of my comment into a > farcical debate on debating was not worth the internet bytes it was > printed on. In fact, that nicely demonstrates one class of technique > commonly used on lkml to silence criticism, and is worth studying from > that viewpoint. That sort of diverting should end, particularly in > regards to the topic at hand. Daniel, the thread has long diverted and has become a philosophical debate. I'm still in CC since almost the beginning because I dared to respond to the *original* discussion (on the subject of how to better tag commits for stable), conscious of the risk I was taking. I've long stopped reading this and am still getting these e-mails which remind me some old tv shows I could occasionally discover when I was a kid, with old daddies with long hair discussing whether writing with a hand in the pocket is better for health than brushing your hair with a plastic brush or not... So I have no problem stating it here : no, this thread doesn't interest me anymore. Only the few first exchanges did (those on the workflow of commits). I could humbly ask to be removed from the CC list, but since -stable is CCed as well I'll still receive these discussions in my mailbox. And given that I'm not the only one to find this one boring, I believe it is not a selfish request from me to kindly ask this thing to stop. After all, 2 or 3 persons sending off-topic e-mails to 10, 20, or even 50k subscribers on a development list might look inadequate to some readers. Thus, I think it would be *polite* from people who entertain this thread while smoking I-don't-know-what, to agree that there will always be some areas where they disagree, that they shake their respective hands and silently quit the scene so that we can turn off the lights and all go to bed. Thanks for your understanding, Willy -- 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/
