* Re: [PATCH 00/36] Staging: cx25821: Clean up patch series
From: Leonid V. Fedorenchik @ 2011-10-24 14:46 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Greg KH, Namhyung Kim, Palash Bandyopadhyay, Joe Perches,
Ilia Mirkin, Youquan Song, devel, linux-kernel
In-Reply-To: <4EA47CF8.2090504@redhat.com>
On Sun, 23 Oct 2011 22:45:44 +0200
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em 23-10-2011 17:24, Leonid V. Fedorenchik escreveu:
> >
> > Thank you. Should I send my future patches for this driver directly to you?
>
> The better is if you could send them to linux-media@vger.kernel.org. Patchwork
> will catch them and put on my queue automatically.
OK, will do. :)
>
> Thanks,
> Mauro
Leonid V. Fedorenchik
^ permalink raw reply
* [PATCH v5 1/7] arm: introduce cross trigger interface helpers
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
OMAP4 uses cross trigger interface(CTI) to route
performance monitor irq to GIC, so introduce cti
helpers to make access for cti easily.
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/cti.h
diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
new file mode 100644
index 0000000..a0ada3e
--- /dev/null
+++ b/arch/arm/include/asm/cti.h
@@ -0,0 +1,179 @@
+#ifndef __ASMARM_CTI_H
+#define __ASMARM_CTI_H
+
+#include <asm/io.h>
+
+/* The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ */
+#define CTICONTROL 0x000
+#define CTISTATUS 0x004
+#define CTILOCK 0x008
+#define CTIPROTECTION 0x00C
+#define CTIINTACK 0x010
+#define CTIAPPSET 0x014
+#define CTIAPPCLEAR 0x018
+#define CTIAPPPULSE 0x01c
+#define CTIINEN 0x020
+#define CTIOUTEN 0x0A0
+#define CTITRIGINSTATUS 0x130
+#define CTITRIGOUTSTATUS 0x134
+#define CTICHINSTATUS 0x138
+#define CTICHOUTSTATUS 0x13c
+#define CTIPERIPHID0 0xFE0
+#define CTIPERIPHID1 0xFE4
+#define CTIPERIPHID2 0xFE8
+#define CTIPERIPHID3 0xFEC
+#define CTIPCELLID0 0xFF0
+#define CTIPCELLID1 0xFF4
+#define CTIPCELLID2 0xFF8
+#define CTIPCELLID3 0xFFC
+
+/* The below are from section 3.6.4 of
+ * CoreSight v1.0 Architecture Specification
+ */
+#define LOCKACCESS 0xFB0
+#define LOCKSTATUS 0xFB4
+
+/* write this value to LOCKACCESS will unlock the module, and
+ * other value will lock the module
+ */
+#define LOCKCODE 0xC5ACCE55
+
+/**
+ * struct cti - cross trigger interface struct
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out_for_irq: triger out number which will cause
+ * the @irq happen
+ *
+ * cti struct used to operate cti registers.
+ */
+struct cti {
+ void __iomem *base;
+ int irq;
+ int trig_out_for_irq;
+};
+
+/**
+ * cti_init - initialize the cti instance
+ * @cti: cti instance
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out: triger out number which will cause
+ * the @irq happen
+ *
+ * called by machine code to pass the board dependent
+ * @base, @irq and @trig_out to cti.
+ */
+static inline void cti_init(struct cti *cti,
+ void __iomem *base, int irq, int trig_out)
+{
+ cti->base = base;
+ cti->irq = irq;
+ cti->trig_out_for_irq = trig_out;
+}
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti: cti instance
+ * @trig_in: trigger in number
+ * @trig_out: trigger out number
+ * @channel: channel number
+ *
+ * This function maps one trigger in of @trig_in to one trigger
+ * out of @trig_out using the channel @chan.
+ */
+static inline void cti_map_trigger(struct cti *cti,
+ int trig_in, int trig_out, int chan)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINEN + trig_in * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIINEN + trig_in * 4);
+
+ val = __raw_readl(base + CTIOUTEN + trig_out * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIOUTEN + trig_out * 4);
+}
+
+/**
+ * cti_enable - enable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_enable(struct cti *cti)
+{
+ __raw_writel(0x1, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_disable - disable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_disable(struct cti *cti)
+{
+ __raw_writel(0, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_irq_ack - clear the cti irq
+ * @cti: cti instance
+ *
+ * clear the cti irq
+ */
+static inline void cti_irq_ack(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINTACK);
+ val |= BIT(cti->trig_out_for_irq);
+ __raw_writel(val, base + CTIINTACK);
+}
+
+/**
+ * cti_unlock - unlock cti module
+ * @cti: cti instance
+ *
+ * unlock the cti module, or else any writes to the cti
+ * module is not allowed.
+ */
+static inline void cti_unlock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (val & 1) {
+ val = LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+
+/**
+ * cti_lock - lock cti module
+ * @cti: cti instance
+ *
+ * lock the cti module, so any writes to the cti
+ * module will be not allowed.
+ */
+static inline void cti_lock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (!(val & 1)) {
+ val = ~LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+#endif
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic
From: Oleg Nesterov @ 2011-10-24 14:41 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli
Cc: Srikar Dronamraju, Peter Zijlstra, Ingo Molnar, Steven Rostedt,
Linux-mm, Arnaldo Carvalho de Melo, Linus Torvalds,
Jonathan Corbet, Masami Hiramatsu, Hugh Dickins,
Christoph Hellwig, Thomas Gleixner, Andi Kleen, Andrew Morton,
Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111022072030.GB24475@in.ibm.com>
On 10/22, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Oct 19, 2011 at 11:53:44PM +0200, Oleg Nesterov wrote:
> > Finally, add UTASK_SSTEP_TRAPPED state/code to handle the case when
> > xol insn itself triggers the signal.
> >
> > In this case we should restart the original insn even if the task is
> > already SIGKILL'ed (say, the coredump should report the correct ip).
> > This is even more important if the task has a handler for SIGSEGV/etc,
> > The _same_ instruction should be repeated again after return from the
> > signal handler, and SSTEP can never finish in this case.
>
> Oleg,
>
> Not sure I understand this completely...
I hope you do not think I do ;)
> When you say 'correct ip' you mean the original vaddr where we now have
> a uprobe breakpoint and not the xol copy, right?
Yes,
> Coredump needs to report the correct ip, but should it also not report
> correctly the instruction that caused the signal? Ergo, shouldn't we
> put the original instruction back at the uprobed vaddr?
OK, now I see what you mean. I was confused by the "restore the original
instruction before _restart_" suggestion.
Agreed! it would be nice to "hide" these int3's if we dump the core, but
I think this is a bit off-topic. It makes sense to do this in any case,
even if the core-dumping was triggered by another thread/insn. It makes
sense to remove all int3's, not only at regs->ip location. But how can
we do this? This is nontrivial.
And. Even worse. Suppose that you do "gdb probed_application". Now you
see int3's in the disassemble output. What can we do?
I think we can do nothing, at least currently. This just reflects the
fact that uprobe connects to inode, not to process/mm/etc.
What do you think?
Oleg.
^ permalink raw reply
* [PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.
This patch is for support of pmu irq routed from CTI on omap4.
Acked-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/include/asm/pmu.h | 15 ++++++++++++---
arch/arm/kernel/perf_event.c | 15 ++++++++++++---
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index b7e82c4..3af5e39 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -22,13 +22,22 @@ enum arm_pmu_type {
/*
* struct arm_pmu_platdata - ARM PMU platform data
*
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ * interrupt and passed the address of the low level handler,
+ * and can be used to implement any platform specific handling
+ * before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ * request_irq and be used to handle some platform specific
+ * irq enablement
+ * @disable_irq: an optional handler which will be called before
+ * free_irq and be used to handle some platform specific
+ * irq disablement
*/
struct arm_pmu_platdata {
irqreturn_t (*handle_irq)(int irq, void *dev,
irq_handler_t pmu_handler);
+ void (*enable_irq)(int irq);
+ void (*disable_irq)(int irq);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 53c9c26..f367780 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -426,14 +426,18 @@ armpmu_reserve_hardware(void)
pr_warning("unable to request IRQ%d for ARM perf "
"counters\n", irq);
break;
- }
+ } else if (plat && plat->enable_irq)
+ plat->enable_irq(irq);
}
if (err) {
for (i = i - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat && plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
release_pmu(ARM_PMU_DEVICE_CPU);
pmu_device = NULL;
@@ -446,11 +450,16 @@ static void
armpmu_release_hardware(void)
{
int i, irq;
+ struct arm_pmu_platdata *plat =
+ dev_get_platdata(&pmu_device->dev);
for (i = pmu_device->num_resources - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat && plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
armpmu->stop();
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:47 UTC (permalink / raw)
To: Mark Brown
Cc: patches, tony, devicetree-discuss, Rajendra Nayak, linux-kernel,
Grant Likely, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134930.GD26033@opensource.wolfsonmicro.com>
On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
>
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
> >
>
> Is that going to do the right thing if you've got a MFD which does
> register each regulator as a separate device?
Based on my understanding, 1:1 is just a special case of N:1. I
failed to see any problem having it work with registering each
regulator as a separate device.
> Might be best to just
> search within dev and get drivers to pass the "real" device in when
> registering the regulator rather than the virtual device.
>
It should also work, but it will also change the API slightly for
non-dt users. I'm not sure it's something we want.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024134930.GD26033@opensource.wolfsonmicro.com>
On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
>
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
> >
>
> Is that going to do the right thing if you've got a MFD which does
> register each regulator as a separate device?
Based on my understanding, 1:1 is just a special case of N:1. I
failed to see any problem having it work with registering each
regulator as a separate device.
> Might be best to just
> search within dev and get drivers to pass the "real" device in when
> registering the regulator rather than the virtual device.
>
It should also work, but it will also change the API slightly for
non-dt users. I'm not sure it's something we want.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v5 3/7] arm: perf: support device with other non-irq resources
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
omap4 may create device via hwmod, which can create resources
automatically, so may include some non-irq resources.
This patch supports device with other non-irq resources.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/kernel/perf_event.c | 5 +++--
arch/arm/kernel/pmu.c | 12 ++++++++++--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f367780..d91dba2 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -19,6 +19,7 @@
#include <linux/platform_device.h>
#include <linux/spinlock.h>
#include <linux/uaccess.h>
+#include <linux/cpumask.h>
#include <asm/cputype.h>
#include <asm/irq.h>
@@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
return -ENODEV;
}
- for (i = 0; i < pmu_device->num_resources; ++i) {
+ for (i = 0; i < nr_cpu_ids; ++i) {
irq = platform_get_irq(pmu_device, i);
if (irq < 0)
continue;
@@ -453,7 +454,7 @@ armpmu_release_hardware(void)
struct arm_pmu_platdata *plat =
dev_get_platdata(&pmu_device->dev);
- for (i = pmu_device->num_resources - 1; i >= 0; --i) {
+ for (i = nr_cpu_ids - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
if (irq >= 0) {
if (plat && plat->disable_irq)
diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
index c53474f..0e9c908 100644
--- a/arch/arm/kernel/pmu.c
+++ b/arch/arm/kernel/pmu.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/cpumask.h>
#include <asm/pmu.h>
@@ -172,8 +173,15 @@ init_cpu_pmu(void)
if (irqs == 1 && !irq_can_set_affinity(platform_get_irq(pdev, 0)))
return 0;
- for (i = 0; i < irqs; ++i) {
- err = set_irq_affinity(platform_get_irq(pdev, i), i);
+ for (i = 0; i < nr_cpu_ids; ++i) {
+ int irq;
+
+ irq = platform_get_irq(pdev, i);
+
+ if (irq < 0)
+ continue;
+
+ err = set_irq_affinity(irq, i);
if (err)
break;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
So that access to cross trigger interface can be allowed, which
will be introduce in later patches.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..c7289a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
+ .name = "emu",
+};
+
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+ { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+ .name = "emu",
+ .class = &omap44xx_emu_hwmod_class,
+ .clkdm_name = "emu_sys_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_emu_irqs,
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5422,6 +5446,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
+ /*emu class*/
+ &omap44xx_emu_hwmod,
NULL,
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 5/7] arm: omap4: create pmu device via hwmod
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
emu, l3_instr, l3_main_3
so build the arm-pmu device via the three hwmods.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 61 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0f8e0eb..6e16274 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -384,14 +384,67 @@ static struct platform_device omap_pmu_device = {
.num_resources = 1,
};
-static void omap_init_pmu(void)
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct omap_device_pm_latency omap_pmu_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static struct platform_device* __init omap4_init_pmu(void)
{
- if (cpu_is_omap24xx())
+ int id = -1;
+ const char *hw;
+ struct platform_device *pd;
+ struct omap_hwmod* oh[3];
+ char *dev_name = "arm-pmu";
+
+ hw = "l3_main_3";
+ oh[0] = omap_hwmod_lookup(hw);
+ if (!oh[0]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+ hw = "l3_instr";
+ oh[1] = omap_hwmod_lookup(hw);
+ if (!oh[1]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+ hw = "emu";
+ oh[2] = omap_hwmod_lookup(hw);
+ if (!oh[2]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+
+ pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
+ sizeof(omap4_pmu_data),
+ omap_pmu_latency,
+ ARRAY_SIZE(omap_pmu_latency), 0);
+ WARN(IS_ERR(pd), "Can't build omap_device for %s.\n",
+ dev_name);
+ return pd;
+}
+static void __init omap_init_pmu(void)
+{
+ if (cpu_is_omap24xx()) {
omap_pmu_device.resource = &omap2_pmu_resource;
- else if (cpu_is_omap34xx())
+ } else if (cpu_is_omap34xx()) {
omap_pmu_device.resource = &omap3_pmu_resource;
- else
+ } else if (cpu_is_omap44xx()) {
+ struct platform_device *pd;
+
+ pd = omap4_init_pmu();
+ if (!pd)
+ return;
+ omap_device_enable(pd);
+ return;
+ } else {
return;
+ }
platform_device_register(&omap_pmu_device);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 6/7] arm: omap4: support pmu
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei,
Woodruff Richard
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
about "Oprofile on Pandaboard / Omap4" on pandaboard@googlegroups.com.
Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Woodruff Richard <r-woodruff2@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 60 +++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap44xx.h | 3 +
2 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 6e16274..bc791e0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -23,6 +23,7 @@
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include <asm/pmu.h>
+#include <asm/cti.h>
#include <plat/tc.h>
#include <plat/board.h>
@@ -393,6 +394,57 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
},
};
+static struct cti omap4_cti[2];
+
+static void omap4_enable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_enable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_enable(&omap4_cti[1]);
+}
+
+static void omap4_disable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_disable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_disable(&omap4_cti[1]);
+}
+
+static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_irq_ack(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_irq_ack(&omap4_cti[1]);
+
+ return handler(irq, dev);
+}
+
+static void __init omap4_configure_pmu_irq(void)
+{
+ void __iomem *base0;
+ void __iomem *base1;
+
+ base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+ base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+ if (!base0 && !base1) {
+ pr_err("ioremap for OMAP4 CTI failed\n");
+ return;
+ }
+
+ /*configure CTI0 for pmu irq routing*/
+ cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+ cti_unlock(&omap4_cti[0]);
+ cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+
+ /*configure CTI1 for pmu irq routing*/
+ cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+ cti_unlock(&omap4_cti[1]);
+ cti_map_trigger(&omap4_cti[1], 1, 6, 2);
+}
+
static struct platform_device* __init omap4_init_pmu(void)
{
int id = -1;
@@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
return NULL;
}
+ omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ omap4_pmu_data.enable_irq = omap4_enable_cti;
+ omap4_pmu_data.disable_irq = omap4_disable_cti;
+
pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
sizeof(omap4_pmu_data),
omap_pmu_latency,
@@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
pd = omap4_init_pmu();
if (!pd)
return;
- omap_device_enable(pd);
+
+ omap_device_enable(&od->pdev);
+ omap4_configure_pmu_irq();
return;
} else {
return;
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..4637980 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,8 @@
#define OMAP44XX_HSUSB_OHCI_BASE (L4_44XX_BASE + 0x64800)
#define OMAP44XX_HSUSB_EHCI_BASE (L4_44XX_BASE + 0x64C00)
+#define OMAP44XX_CTI0_BASE 0x54148000
+#define OMAP44XX_CTI1_BASE 0x54149000
+
#endif /* __ASM_ARCH_OMAP44XX_H */
--
1.7.5.4
^ permalink raw reply related
* Re: match a few ecn-ip-ect in one rule
From: Jan Engelhardt @ 2011-10-24 14:48 UTC (permalink / raw)
To: Sergey Naumov; +Cc: netfilter
In-Reply-To: <CAH3pVZPTgqtPeHRvjQdaq+2Ekm-ZKBaX1TCz7fVX+uAEHoFXAA@mail.gmail.com>
On Monday 2011-10-24 13:59, Sergey Naumov wrote:
>> Since rules are generally combined in ORed, it only makes sense for
>> matches to be ANDed (and submatch parts to be ORed at times).
>
>Yes, I understand, but because of logic of project that I develop it
>is better to use 1 rule than to search places where I have to add
>workarounds to generate 2 iptables rules from 1 user specified rule.
>When I use multiple -m molude inclusions, are specified parameters
>combined as OR, as AND or overrided?
Like I said, AND. Otherwise, packets would be able to match -m statistic
--mode random --probability 0 [-m something else].
^ permalink raw reply
* [PATCH v5 7/7] arm: omap4: pmu: support runtime pm
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index bc791e0..ab4de0d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/pm_runtime.h>
#include <mach/hardware.h>
#include <mach/irqs.h>
@@ -395,9 +396,11 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
};
static struct cti omap4_cti[2];
+static struct platform_device *pmu_dev;
static void omap4_enable_cti(int irq)
{
+ pm_runtime_get_sync(&pmu_dev->dev);
if (irq == OMAP44XX_IRQ_CTI0)
cti_enable(&omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
@@ -410,6 +413,7 @@ static void omap4_disable_cti(int irq)
cti_disable(&omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
cti_disable(&omap4_cti[1]);
+ pm_runtime_put(&pmu_dev->dev);
}
static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
@@ -497,8 +501,11 @@ static void __init omap_init_pmu(void)
if (!pd)
return;
- omap_device_enable(&od->pdev);
+ pmu_dev= pd;
+ pm_runtime_enable(&pd->dev);
+ pm_runtime_get_sync(&pd->dev);
omap4_configure_pmu_irq();
+ pm_runtime_put(&pd->dev);
return;
} else {
return;
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 2/2] ARM: at91: add at91sam9g20 and Calao USB A9G20 DT support
From: Rob Herring @ 2011-10-24 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d139db89b4e9830e813abf1329ce1ac499653f2c.1319464310.git.nicolas.ferre@atmel.com>
On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
Looks good.
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* Re: [PATCH V3 2/2] ARM: at91: add at91sam9g20 and Calao USB A9G20 DT support
From: Rob Herring @ 2011-10-24 14:49 UTC (permalink / raw)
To: Nicolas Ferre
Cc: grant.likely, linux-kernel, linux-arm-kernel, devicetree-discuss,
plagnioj
In-Reply-To: <d139db89b4e9830e813abf1329ce1ac499653f2c.1319464310.git.nicolas.ferre@atmel.com>
On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
Looks good.
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* Re: [PATCH] TTY: pty, fix pty counting
From: Ilya Zykov @ 2011-10-24 14:50 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg Kroah-Hartman, Alan Cox, linux-kernel, ilya
In-Reply-To: <4EA563E6.3040205@suse.cz>
Jiri Slaby wrote:
> On 10/23/2011 11:01 PM, Ilya Zykov wrote:
>> New version for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
>
> Although it will work, as ptms are not allowed to be reopen, it doesn't
> look correct. We should decrement the count in ->remove, because we are
> incrementing in install.
>
> Now, when I understand ptm+devpts layer a bit more, instead of the
> current hackish approach introduced by 24d406a6b (TTY: pty, fix pty
> counting), I think we may introduce a ->remove hook specific to ptms. In
> that one we could decrement the count and don't bother with the
> pty_count macros anymore. Right?
>
> BTW you cannot remove ->remove hook of pty layer. It would cause an OOPS
> because driver->ttys is not allocated for ptys.
>
>> diff -uprN a/drivers/tty/pty.c b/drivers/tty/pty.c
>> --- a/drivers/tty/pty.c 2011-05-19 08:06:34.000000000 +0400
>> +++ b/drivers/tty/pty.c 2011-10-23 18:01:20.000000000 +0400
>> @@ -36,13 +36,15 @@
>> static struct tty_driver *ptm_driver;
>> static struct tty_driver *pts_driver;
>> #endif
>> +static int pty_count;
>>
>> static void pty_close(struct tty_struct *tty, struct file *filp)
>> {
>> BUG_ON(!tty);
>> - if (tty->driver->subtype == PTY_TYPE_MASTER)
>> + if (tty->driver->subtype == PTY_TYPE_MASTER) {
>> WARN_ON(tty->count > 1);
>> - else {
>> + pty_count--;
>> + } else {
>> if (tty->count > 2)
>> return;
>> }
>> @@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
>> int pty_limit = NR_UNIX98_PTY_DEFAULT;
>> static int pty_limit_min;
>> static int pty_limit_max = NR_UNIX98_PTY_MAX;
>> -static int pty_count;
>>
>> static struct cdev ptmx_cdev;
>>
>> @@ -599,15 +600,9 @@ free_mem_out:
>> return -ENOMEM;
>> }
>>
>> -static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty)
>> -{
>> - pty_count--;
>> -}
>> -
>> static const struct tty_operations ptm_unix98_ops = {
>> .lookup = ptm_unix98_lookup,
>> .install = pty_unix98_install,
>> - .remove = pty_unix98_remove,
>> .open = pty_open,
>> .close = pty_close,
>> .write = pty_write,
>> @@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
>> static const struct tty_operations pty_unix98_ops = {
>> .lookup = pts_unix98_lookup,
>> .install = pty_unix98_install,
>> - .remove = pty_unix98_remove,
>> .open = pty_open,
>> .close = pty_close,
>> .write = pty_write,
>
> thanks,
Invoke tty_driver_remove_tty() from driver,
not good idea IMHO.
^ permalink raw reply
* Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
From: Thomas Hellstrom @ 2011-10-24 14:48 UTC (permalink / raw)
To: Marek Olšák; +Cc: dri-devel
In-Reply-To: <CAAxE2A6uJzg0Uvvehzd2YVYZtAAE-hBBik2G77QAEfZ9bU5wJg@mail.gmail.com>
On 10/08/2011 12:03 AM, Marek Olšák wrote:
> On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom<thomas@shipmail.org> wrote:
>
>> OK. First I think we need to make a distinction: bo sync objects vs driver
>> fences. The bo sync obj api is there to strictly provide functionality that
>> the ttm bo subsystem is using, and that follows a simple set of rules:
>>
>> 1) the bo subsystem does never assume sync objects are ordered. That means
>> the bo subsystem needs to wait on a sync object before removing it from a
>> buffer. Any other assumption is buggy and must be fixed. BUT, if that
>> assumption takes place in the driver unknowingly from the ttm bo subsystem
>> (which is usually the case), it's OK.
>>
>> 2) When the sync object(s) attached to the bo are signaled the ttm bo
>> subsystem is free to copy the bo contents and to unbind the bo.
>>
>> 3) The ttm bo system allows sync objects to be signaled in different ways
>> opaque to the subsystem using sync_obj_arg. The driver is responsible for
>> setting up that argument.
>>
>> 4) Driver fences may be used for or expose other functionality or adaptions
>> to APIs as long as the sync obj api exported to the bo sybsystem follows the
>> above rules.
>>
>> This means the following w r t the patch.
>>
>> A) it violates 1). This is a bug that must be fixed. Assumptions that if one
>> sync object is singnaled, another sync object is also signaled must be done
>> in the driver and not in the bo subsystem. Hence we need to explicitly wait
>> for a fence to remove it from the bo.
>>
>> B) the sync_obj_arg carries *per-sync-obj* information on how it should be
>> signaled. If we need to attach multiple sync objects to a buffer object, we
>> also need multiple sync_obj_args. This is a bug and needs to be fixed.
>>
>> C) There is really only one reason that the ttm bo subsystem should care
>> about multiple sync objects, and that is because the driver can't order them
>> efficiently. A such example would be hardware with multiple pipes reading
>> simultaneously from the same texture buffer. Currently we don't support this
>> so only the *last* sync object needs to be know by the bo subsystem. Keeping
>> track of multiple fences generates a lot of completely unnecessary code in
>> the ttm_bo_util file, the ttm_bo_vm file, and will be a nightmare if / when
>> we truly support pipelined moves.
>>
>> As I understand it from your patches, you want to keep multiple fences
>> around only to track rendering history. If we want to do that generically, i
>> suggest doing it in the execbuf util code in the following way:
>>
>> struct ttm_eu_rendering_history {
>> void *last_read_sync_obj;
>> void *last_read_sync_obj_arg;
>> void *last_write_sync_obj;
>> void *last_write_sync_obj_arg;
>> }
>>
>> Embed this structure in the radeon_bo, and build a small api around it,
>> including *optionally* passing it to the existing execbuf utilities, and you
>> should be done. The bo_util code and bo_vm code doesn't care about the
>> rendering history. Only that the bo is completely idle.
>>
>> Note also that when an accelerated bo move is scheduled, the driver needs to
>> update this struct
>>
> OK, sounds good. I'll fix what should be fixed and send a patch when
> it's ready. I am now not so sure whether doing this generically is a
> good idea. :)
>
> Marek
>
Marek,
Any progress on this. The merge window is about to open soon I guess and
we need a fix by then.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: NFS4 BAD_STATEID loop (kernel 3.0.4)
From: David Flynn @ 2011-10-24 14:50 UTC (permalink / raw)
To: Trond Myklebust; +Cc: David Flynn, linux-nfs, Chuck Lever
In-Reply-To: <1319463165.2734.1.camel@lade.trondhjem.org>
* Chuck Lever (chuck.lever@oracle.com) wrote:
> Can you tell us a little more about the server? Which release of
> Solaris? What hardware?
SunOS 5.10 Generic_141444-09
(sparc)
* Trond Myklebust (Trond.Myklebust@netapp.com) wrote:
> I'm assuming then that your network trace showed no sign of any OPEN
> calls of that particular file, just retries of the WRITE?
Correct.
However, the good news is that it has just happened again (certainly
not quota related)
The blocked task:
[179068.773206] INFO: task bash:3293 blocked for more than 120 seconds.
[179068.779660] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[179068.787701] bash D 0000000000000004 0 3293 1 0x00000000
[179068.795173] ffff88001f97fca8 0000000000000086 ffff880426876008 0000000000012a40
[179068.802992] ffff88001f97ffd8 0000000000012a40 ffff88001f97e000 0000000000012a40
[179068.810745] 0000000000012a40 0000000000012a40 ffff88001f97ffd8 0000000000012a40
[179068.818810] Call Trace:
[179068.821496] [<ffffffff81110030>] ? __lock_page+0x70/0x70
[179068.827204] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
[179068.832952] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
[179068.838823] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
[179068.844734] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
[179068.850798] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
[179068.857879] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
[179068.864173] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
[179068.870721] [<ffffffffa02167d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
[179068.877963] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
[179068.883744] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
[179068.890867] [<ffffffff81111730>] filemap_write_and_wait_range+0x70/0x80
[179068.898025] [<ffffffff8119cc6a>] vfs_fsync_range+0x5a/0x90
[179068.904197] [<ffffffff8119cd0c>] vfs_fsync+0x1c/0x20
[179068.909721] [<ffffffffa020ac74>] nfs_file_flush+0x54/0x80 [nfs]
[179068.916069] [<ffffffff8116ee7f>] filp_close+0x3f/0x90
[179068.921611] [<ffffffff8116f8a7>] sys_close+0xb7/0x120
[179068.927328] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
$ echo 0 >/proc/sys/sunrpc/rpc_debug
[180179.009328] -pid- flgs status -client- --rqstp- -timeout ---ops--
[180179.015540] 40304 0801 0 ffff8804241ae800 (null) 0 ffffffffa023cd40 nfsv4 WRITE a:call_start q:NFS client
and our pingpong (more details at end):
14:07:07.307191 IP vc-fs1.rd.bbc.co.uk.1837702678 > home.rd.bbc.co.uk.nfs: 300 getattr fh 0,0/22
14:07:07.307471 IP home.rd.bbc.co.uk.nfs > vc-fs1.rd.bbc.co.uk.1837702678: reply ok 52 getattr ERROR: unk 10025
This system is up at the moment, if there is further detail you require
i can provide that.
NB, the system this occurred on is running kernel 3.0.4
Mount options as per earlier.
Kind regards,
..david
No. Time Source Destination Protocol Size Info
39 15:33:59.077143 172.29.190.28 172.29.120.140 NFS 370 V4 COMPOUND Call (Reply In 40) <EMPTY> PUTFH;WRITE;GETATTR
Frame 39: 370 bytes on wire (2960 bits), 370 bytes captured (2960 bits)
Ethernet II, Src: ChelsioC_07:49:6f (00:07:43:07:49:6f), Dst: All-HSRP-routers_be (00:00:0c:07:ac:be)
Internet Protocol, Src: 172.29.190.28 (172.29.190.28), Dst: 172.29.120.140 (172.29.120.140)
Transmission Control Protocol, Src Port: omginitialrefs (900), Dst Port: nfs (2049), Seq: 40433, Ack: 7449, Len: 304
Remote Procedure Call, Type:Call XID:0x43ce4e16
Network File System
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Tag: <EMPTY>
length: 0
contents: <EMPTY>
minorversion: 0
Operations (count: 3)
Opcode: PUTFH (22)
filehandle
length: 36
[hash (CRC-32): 0x6e4b15f3]
decode type as: unknown
filehandle: 7df3a75d5e1cd908000ab44c5b000000efc80200000a0300...
Opcode: WRITE (38)
stateid
offset: 11474
stable: FILE_SYNC4 (2)
Write length: 68
Data: <DATA>
length: 68
contents: <DATA>
Opcode: GETATTR (9)
GETATTR4args
attr_request
bitmap[0] = 0x00000018
[2 attributes requested]
mand_attr: FATTR4_CHANGE (3)
mand_attr: FATTR4_SIZE (4)
bitmap[1] = 0x00300000
[2 attributes requested]
recc_attr: FATTR4_TIME_METADATA (52)
recc_attr: FATTR4_TIME_MODIFY (53)
No. Time Source Destination Protocol Size Info
40 15:33:59.077433 172.29.120.140 172.29.190.28 NFS 122 V4 COMPOUND Reply (Call In 39) <EMPTY> PUTFH;WRITE
Frame 40: 122 bytes on wire (976 bits), 122 bytes captured (976 bits)
Ethernet II, Src: Cisco_1e:f7:80 (00:13:5f:1e:f7:80), Dst: ChelsioC_07:49:6f (00:07:43:07:49:6f)
Internet Protocol, Src: 172.29.120.140 (172.29.120.140), Dst: 172.29.190.28 (172.29.190.28)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: omginitialrefs (900), Seq: 7449, Ack: 40737, Len: 56
Remote Procedure Call, Type:Reply XID:0x43ce4e16
Network File System
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Status: NFS4ERR_BAD_STATEID (10025)
Tag: <EMPTY>
length: 0
contents: <EMPTY>
Operations (count: 2)
Opcode: PUTFH (22)
Status: NFS4_OK (0)
Opcode: WRITE (38)
Status: NFS4ERR_BAD_STATEID (10025)
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:51 UTC (permalink / raw)
To: Grant Likely
Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024135950.GV8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > >
> > > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > > when calling regulator_register(regulator_desc, dev, ...) from
> > > > regulator driver, the regulator core will be able to find all nodes under
> > > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> > >
> > > Please provide concrete examples of the bindings you're talking about,
> > > the really important thing here is how sane the bindings look and I've
> > > really got no idea what any of what you're talking about will look like
> > > or if they make sense.
> > >
> > The only thing different from what I attached last time is the
> > compatible string added to 'regulators' node.
> >
> > ecspi@70010000 { /* ECSPI1 */
> > fsl,spi-num-chipselects = <2>;
> > cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> > <&gpio3 25 0>; /* GPIO4_25 */
> > status = "okay";
> >
> > pmic: mc13892@0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,mc13892";
> > spi-max-frequency = <6000000>;
> > reg = <0>;
> > mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
> >
> > regulators {
> > compatible = "fsl,mc13892-regulator";
> >
> > sw1reg: mc13892_sw1 {
> > regulator-min-uV = <600000>;
> > regulator-max-uV = <1375000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > sw2reg: mc13892_sw2 {
> > regulator-min-uV = <900000>;
> > regulator-max-uV = <1850000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > ......
> > };
> >
> > leds {
> > ......
> > };
> >
> > buttons {
> > ......
> > };
> > };
> >
> > flash: at45db321d@1 {
> > ......
> > };
> > };
> >
> > > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > > "fsl,mc13892-regulators").
> > >
> > > It's not immediately obvious to me that having a binding for the
> > > regulators separately makes sense, it's not a usefully distinct device.
> > >
> > Fair point. Actually, I also hate to have the finding of node
> > 'regulators' plugged into regulator driver. What about following
> > change to address Grant's concern on global device tree search?
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 8fe132d..29dcf90 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
>
> of_find_node_by_name() doesn't work that way. The first argument is a
> starting point, but it doesn't restrict the search to children of a
> node.
>
> for_each_child_of_node() is what you want to use when iterating over
> the children which unfortunately changes the structure of this
> function.
>
The dev->parent->of_node is meant to point to node 'pmic: mc13892@0'.
And the intention here is not to iterate over the children, but to
start a search from a reasonable point rather than the top root node.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024135950.GV8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > >
> > > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > > when calling regulator_register(regulator_desc, dev, ...) from
> > > > regulator driver, the regulator core will be able to find all nodes under
> > > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> > >
> > > Please provide concrete examples of the bindings you're talking about,
> > > the really important thing here is how sane the bindings look and I've
> > > really got no idea what any of what you're talking about will look like
> > > or if they make sense.
> > >
> > The only thing different from what I attached last time is the
> > compatible string added to 'regulators' node.
> >
> > ecspi at 70010000 { /* ECSPI1 */
> > fsl,spi-num-chipselects = <2>;
> > cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> > <&gpio3 25 0>; /* GPIO4_25 */
> > status = "okay";
> >
> > pmic: mc13892 at 0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,mc13892";
> > spi-max-frequency = <6000000>;
> > reg = <0>;
> > mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
> >
> > regulators {
> > compatible = "fsl,mc13892-regulator";
> >
> > sw1reg: mc13892_sw1 {
> > regulator-min-uV = <600000>;
> > regulator-max-uV = <1375000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > sw2reg: mc13892_sw2 {
> > regulator-min-uV = <900000>;
> > regulator-max-uV = <1850000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > ......
> > };
> >
> > leds {
> > ......
> > };
> >
> > buttons {
> > ......
> > };
> > };
> >
> > flash: at45db321d at 1 {
> > ......
> > };
> > };
> >
> > > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > > "fsl,mc13892-regulators").
> > >
> > > It's not immediately obvious to me that having a binding for the
> > > regulators separately makes sense, it's not a usefully distinct device.
> > >
> > Fair point. Actually, I also hate to have the finding of node
> > 'regulators' plugged into regulator driver. What about following
> > change to address Grant's concern on global device tree search?
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 8fe132d..29dcf90 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
>
> of_find_node_by_name() doesn't work that way. The first argument is a
> starting point, but it doesn't restrict the search to children of a
> node.
>
> for_each_child_of_node() is what you want to use when iterating over
> the children which unfortunately changes the structure of this
> function.
>
The dev->parent->of_node is meant to point to node 'pmic: mc13892 at 0'.
And the intention here is not to iterate over the children, but to
start a search from a reasonable point rather than the top root node.
--
Regards,
Shawn
^ permalink raw reply
* [refpolicy] Error when using refpolicy with apache httpd service
From: Justin Mattock @ 2011-10-24 14:53 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <1319430331.81049.YahooMailNeo@web114307.mail.gq1.yahoo.com>
----- Original Message -----
From: Justin Mattock <justinmattock@yahoo.com>
To: Guido Trentalancia <guido@trentalancia.com>; Dominick Grift <dominick.grift@gmail.com>
Cc: refpolicy <refpolicy@oss.tresys.com>
Sent: Sunday, October 23, 2011 9:25 PM
Subject: Re: [refpolicy] Error when using refpolicy with apache httpd service
----- Original Message -----
From: Guido Trentalancia <guido@trentalancia.com>
To: Dominick Grift <dominick.grift@gmail.com>
Cc: refpolicy <refpolicy@oss.tresys.com>
Sent: Wednesday, October 12, 2011 8:39 AM
Subject: Re: [refpolicy] Error when using refpolicy with apache httpd service
On Wed, 2011-10-12 at 17:15 +0200, Dominick Grift wrote:
> On Thu, 2011-10-13 at 00:08 +0900, Thu?n ?inh wrote:
> > Hi,
> >
> >
> > I'm very strange that the /sbin/init is labeled bin_t
> >
> >
> > The /sbin/init is point to /bin/systemd
> >
> >
> > I check in the /system/init.fc have defiled:
> >
> >
> > /sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
> > # because nowadays, /sbin/init is often a symlink to /sbin/upstart
> > /sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > So, I changed it to:
> >
> >
> > /bin/systemd? ?? -- gen_context(system_u:object_r:init_exec_t,s0)
> > /sbin/init? ? ? ? --
> >? gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > And then, I make, install, load and relabel it again.
> >
> >
> > But after that, the /sbin/init still have labeled bin_t (instead of
> > the /bin/systemd is now have init_exec_t)
> >
> >
> > I'm very strange. So, I try to relabel it by command:
> >
> >
> > chcon -t init_exec_t /sbin/init
>
> The /sbin/init symbolic link can be bin_t, no problem.
>
> /sbin/systemd though should be type init_exec_t.
>
> The problem is that reference policy currently does not support systemd.
>
> systemd is not stable yet.
>
> refpolicy is waiting until systemd is stable before she will support it,
> because there are too many changes happening to systemd currently.
>
> You could probably, atleast to some extend, work around the issues by
> making init a unconfined domain, but that will probably cause issues as
> well. So if you are not comfortable with selinux you may want to avoid
> that.
>
> ?nstead use the policy provided/supported by your distribution instead.
Consider Justin Mattock has recently submitted an initial patch (derived
from F15, I suppose) for better supporting systemd in the reference
policy:
18th September 2011
[RFC 1/2]selinux-contrib: add systemd support to refpolicy git
[RFC 2/2] refpolicy: add systemd support to tresys main policy
It's probably worth trying that out (along with the init_systemd
boolean), if it's using systemd...
Regards,
Guido
yeah, anybody have the time to go through that patch set feel free..
last I remember I was hitting some sandbox error for some reason, then ran out of?
time due to external obligations. maybe if the weekend is permitting I can have another go at
it.. as for the patch I pretty much just grepped dans git tree for systemd then copied it to refpolicy,
but there is probably more to it than just grepping.
Justin P. Mattock?
doing a google search I am only able to find find the first revision sent for this on the 18th of september.
seems my second revision did not make it through to the list. anyway here is my backup of the two patches..:
http://fpaste.org/FLfg/
http://fpaste.org/5r5t/
I will try and plug this in again over the weekend to see if I can get it running. ?
cheers,
Justin P. Mattock
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
^ permalink raw reply
* [Buildroot] [PATCH 1/2] kernel-headers: bump to version 3.0.7 and add version 3.1
From: Gustavo Zacarias @ 2011-10-24 14:54 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
| 8 ++++++--
| 2 +-
...all-fix-__packed-in-exported-kernel-head.patch} | 0
3 files changed, 7 insertions(+), 3 deletions(-)
rename toolchain/kernel-headers/{linux-3.0.4-headers_install-fix-__packed-in-exported-kernel-head.patch => linux-3.0.7-headers_install-fix-__packed-in-exported-kernel-head.patch} (100%)
--git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index b827ec5..8be9186 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -6,7 +6,7 @@ comment "Kernel Header Options"
choice
prompt "Kernel Headers"
- default BR2_KERNEL_HEADERS_3_0
+ default BR2_KERNEL_HEADERS_3_1
help
Select the version of kernel header files you wish to use.
You must select the correct set of header files to match
@@ -33,6 +33,9 @@ choice
config BR2_KERNEL_HEADERS_3_0
bool "Linux 3.0.x kernel headers"
+ config BR2_KERNEL_HEADERS_3_1
+ bool "Linux 3.1.x kernel headers"
+
config BR2_KERNEL_HEADERS_VERSION
bool "Linux 2.6 (manually specified version)"
@@ -54,6 +57,7 @@ config BR2_DEFAULT_KERNEL_HEADERS
default "2.6.37.6" if BR2_KERNEL_HEADERS_2_6_37
default "2.6.38.8" if BR2_KERNEL_HEADERS_2_6_38
default "2.6.39.4" if BR2_KERNEL_HEADERS_2_6_39
- default "3.0.4" if BR2_KERNEL_HEADERS_3_0
+ default "3.0.7" if BR2_KERNEL_HEADERS_3_0
+ default "3.1" if BR2_KERNEL_HEADERS_3_1
default "2.6" if BR2_KERNEL_HEADERS_SNAP
default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
--git a/toolchain/kernel-headers/kernel-headers.mk b/toolchain/kernel-headers/kernel-headers.mk
index 044fcf9..72c6007 100644
--- a/toolchain/kernel-headers/kernel-headers.mk
+++ b/toolchain/kernel-headers/kernel-headers.mk
@@ -29,7 +29,7 @@ LINUX_HEADERS_VERSION:=$(VERSION).$(PATCHLEVEL)$(SUBLEVEL)$(EXTRAVERSION)
ifeq ($(findstring x2.6.,x$(DEFAULT_KERNEL_HEADERS)),x2.6.)
LINUX_HEADERS_SITE:=$(BR2_KERNEL_MIRROR)/linux/kernel/v2.6/
else
-LINUX_HEADERS_SITE:=$(BR2_KERNEL_MIRROR)/linux/kernel/v3.0/
+LINUX_HEADERS_SITE:=$(BR2_KERNEL_MIRROR)/linux/kernel/v3.x/
endif
LINUX_HEADERS_SOURCE:=linux-$(LINUX_HEADERS_VERSION).tar.bz2
LINUX_HEADERS_CAT:=$(BZCAT)
diff --git a/toolchain/kernel-headers/linux-3.0.4-headers_install-fix-__packed-in-exported-kernel-head.patch b/toolchain/kernel-headers/linux-3.0.7-headers_install-fix-__packed-in-exported-kernel-head.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-3.0.4-headers_install-fix-__packed-in-exported-kernel-head.patch
rename to toolchain/kernel-headers/linux-3.0.7-headers_install-fix-__packed-in-exported-kernel-head.patch
--
1.7.3.4
^ permalink raw reply related
* [Buildroot] [PATCH 2/2] linux: bump default kernel to version 3.1
From: Gustavo Zacarias @ 2011-10-24 14:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1319468043-22999-1-git-send-email-gustavo@zacarias.com.ar>
Bump default kernel vesion to 3.1 to match headers.
Also implement downloads for 3.x series kernels.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
linux/Config.in | 10 +++++-----
linux/linux.mk | 8 +++++---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index 5655286..774aaf8 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -19,10 +19,10 @@ if BR2_LINUX_KERNEL
#
choice
prompt "Kernel version"
- default BR2_LINUX_KERNEL_2_6_39
+ default BR2_LINUX_KERNEL_3_1
-config BR2_LINUX_KERNEL_2_6_39
- bool "2.6.39.4"
+config BR2_LINUX_KERNEL_3_1
+ bool "3.1"
config BR2_LINUX_KERNEL_SAME_AS_HEADERS
bool "Same as toolchain kernel headers"
@@ -58,7 +58,7 @@ endchoice
config BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE
string "Kernel version"
depends on BR2_LINUX_KERNEL_CUSTOM_VERSION
- default "2.6.39.4"
+ default "3.1"
config BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION
string "URL of custom kernel tarball"
@@ -74,7 +74,7 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
config BR2_LINUX_KERNEL_VERSION
string
- default "2.6.39.4" if BR2_LINUX_KERNEL_2_6_39
+ default "3.1" if BR2_LINUX_KERNEL_3_1
default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
diff --git a/linux/linux.mk b/linux/linux.mk
index 99f4649..6b6fd5c 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -18,9 +18,11 @@ LINUX_SOURCE = linux-$(LINUX_VERSION).tar.bz2
# In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order
# to use the $(word) function. We support versions such as 3.1,
# 2.6.32, 2.6.32-rc1, 3.0-rc6, etc.
-LINUX_VERSION_MAJOR = $(word 1,$(subst ., ,$(subst -, ,$(LINUX_VERSION))))
-LINUX_VERSION_MINOR = $(word 2,$(subst ., ,$(subst -, ,$(LINUX_VERSION))))
-LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v$(LINUX_VERSION_MAJOR).$(LINUX_VERSION_MINOR)/
+ifeq ($(findstring x2.6.,x$(LINUX_VERSION)),x2.6.)
+LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v2.6/
+else
+LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v3.x/
+endif
# release candidates are in testing/ subdir
ifneq ($(findstring -rc,$(LINUX_VERSION)),)
LINUX_SITE := $(LINUX_SITE)testing/
--
1.7.3.4
^ permalink raw reply related
* kdump: crash_kexec()-smp_send_stop() race in panic
From: Michael Holzheu @ 2011-10-24 14:55 UTC (permalink / raw)
To: Vivek Goyal
Cc: ebiederm, akpm, schwidefsky, heiko.carstens, kexec, linux-kernel
Hello Vivek,
In our tests we ran into the following scenario:
Two CPUs have called panic at the same time. The first CPU called
crash_kexec() and the second CPU called smp_send_stop() in panic()
before crash_kexec() finished on the first CPU. So the second CPU
stopped the first CPU and therefore kdump failed.
1st CPU:
panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
2nd CPU:
panic()->crash_kexec()->kexec_mutex already held by 1st CPU
->smp_send_stop()-> stop CPU 1 (stop kdump)
How should we fix this problem? One possibility could be to do
smp_send_stop() before we call crash_kexec().
What do you think?
Michael
^ permalink raw reply
* kdump: crash_kexec()-smp_send_stop() race in panic
From: Michael Holzheu @ 2011-10-24 14:55 UTC (permalink / raw)
To: Vivek Goyal
Cc: heiko.carstens, kexec, linux-kernel, ebiederm, schwidefsky, akpm
Hello Vivek,
In our tests we ran into the following scenario:
Two CPUs have called panic at the same time. The first CPU called
crash_kexec() and the second CPU called smp_send_stop() in panic()
before crash_kexec() finished on the first CPU. So the second CPU
stopped the first CPU and therefore kdump failed.
1st CPU:
panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
2nd CPU:
panic()->crash_kexec()->kexec_mutex already held by 1st CPU
->smp_send_stop()-> stop CPU 1 (stop kdump)
How should we fix this problem? One possibility could be to do
smp_send_stop() before we call crash_kexec().
What do you think?
Michael
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH 0/2] mmc: mmci: Improvements for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel; +Cc: Russell King, Ulf Hansson, Lee Jones
For the ux500v2 variant of the PL18x block, non power of two block
sizes are now supported.
In addition constraints on buffer alignments is needed since access to the
PL18x FIFO must be done on a 4-byte aligned manner. Moreover to be able to
use DMA for buffers with not 32 bytes aligned sg element lengths, DMAREQCTL
must enabled.
Per Forlin (1):
mmc: mmci: add constraints on alignment for SDIO
Stefan Nilsson XK (1):
mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
drivers/mmc/host/mmci.c | 56 +++++++++++++++++++++++++++++++++++++++++------
drivers/mmc/host/mmci.h | 7 ++++++
2 files changed, 56 insertions(+), 7 deletions(-)
--
1.7.5.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.