Re: [PATCH] arch/arm/mach-pxa/stargate2.c: use ARRAY_AND_SIZE consistently
On Sun, 11 Aug 2013, Dan Carpenter wrote: > ARRAY_AND_SIZE() macro is horrible, and I would like it if it were > removed. What I meant before was just that probably people will > probably complain if we try to remove it. Well, I could either wait for someone to defend it, or send a patch getting rid of it and see what happens... I can't see what could go wrong with f(..., - ARRAY_AND_SIZE(e) + e, ARRAY_SIZE(e) , ...) so it should be an easy patch to create. julia -- 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 RESEND V13 14/14] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor
* Raghavendra K T [2013-08-09 19:52:02]:
>From 10e92f7911a8aed5b8574f53607ffc5d094d4de1 Mon Sep 17 00:00:00 2001
From: Srivatsa Vaddagiri
Date: Tue, 6 Aug 2013 14:55:41 +0530
Subject: [PATCH V13 RESEND 14/14] kvm : Paravirtual ticketlocks support for
linux
guests running on KVM hypervisor
During smp_boot_cpus paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PV_UNHALT) to support pv-ticketlocks. If so,
support for pv-ticketlocks is registered via pv_lock_ops.
Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
Signed-off-by: Srivatsa Vaddagiri
Signed-off-by: Suzuki Poulose
[Raghu: check_zero race fix, enum for kvm_contention_stat, jumplabel related
changes,
addition of safe_halt for irq enabled case, bailout spinning in nmi case(Gleb)
move kvm_vcpu_kick inside CONFIG_PARAVIRT_SPINLOCK to fix UP compilation]
Signed-off-by: Raghavendra K T
Acked-by: Gleb Natapov
Acked-by: Ingo Molnar
---
arch/x86/include/asm/kvm_para.h | 14 ++-
arch/x86/kernel/kvm.c | 262
2 files changed, 274 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 695399f..427afcb 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -118,10 +118,20 @@ void kvm_async_pf_task_wait(u32 token);
void kvm_async_pf_task_wake(u32 token);
u32 kvm_read_and_reset_pf_reason(void);
extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* !CONFIG_PARAVIRT_SPINLOCKS */
+static inline void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
#define kvm_async_pf_task_wait(T) do {} while(0)
#define kvm_async_pf_task_wake(T) do {} while(0)
+
static inline u32 kvm_read_and_reset_pf_reason(void)
{
return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index a96d32c..d442471 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -419,6 +420,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
WARN_ON(kvm_register_clock("primary cpu clock"));
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
+ kvm_spinlock_init();
}
static void kvm_guest_cpu_online(void *dummy)
@@ -523,3 +525,263 @@ static __init int activate_jump_labels(void)
return 0;
}
arch_initcall(activate_jump_labels);
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+/* Kick a cpu by its apicid. Used to wake up a halted vcpu */
+void kvm_kick_cpu(int cpu)
+{
+ int apicid;
+ unsigned long flags = 0;
+
+ apicid = per_cpu(x86_cpu_to_apicid, cpu);
+ kvm_hypercall2(KVM_HC_KICK_CPU, flags, apicid);
+}
+
+enum kvm_contention_stat {
+ TAKEN_SLOW,
+ TAKEN_SLOW_PICKUP,
+ RELEASED_SLOW,
+ RELEASED_SLOW_KICKED,
+ NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+#define HISTO_BUCKETS 30
+
+static struct kvm_spinlock_stats
+{
+ u32 contention_stats[NR_CONTENTION_STATS];
+ u32 histo_spin_blocked[HISTO_BUCKETS+1];
+ u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+ u8 ret;
+ u8 old;
+
+ old = ACCESS_ONCE(zero_stats);
+ if (unlikely(old)) {
+ ret = cmpxchg(_stats, old, 0);
+ /* This ensures only one fellow resets the stat */
+ if (ret == old)
+ memset(_stats, 0, sizeof(spinlock_stats));
+ }
+}
+
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+ check_zero();
+ spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+ return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+ unsigned index;
+
+ index = ilog2(delta);
+ check_zero();
+
+ if (index < HISTO_BUCKETS)
+ array[index]++;
+ else
+ array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+ u32 delta;
+
+ delta = sched_clock() - start;
+ __spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+ spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+ d_kvm_debug = debugfs_create_dir("kvm", NULL);
+ if (!d_kvm_debug)
+ printk(KERN_WARNING "Could not create 'kvm' debugfs
directory\n");
+
+ return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+ struct dentry *d_kvm;
+
+ d_kvm = kvm_init_debugfs();
+ if (d_kvm == NULL)
+ return -ENOMEM;
+
+
Re: [PATCH] 9p: send uevent after adding/removing mount_tag attribute
On Sun, Aug 11, 2013 at 12:53:45AM -0400, Michael Marineau wrote: > This driver adds an attribute to the existing virtio device so a CHANGE > event is required in order udev rules to make use of it. The ADD event > happens before this driver is probed and unlike a more typical driver > like a block device there isn't a higher level device to watch for. > > Signed-off-by: Michael Marineau > --- > net/9p/trans_virtio.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c > index e1c26b1..990afab 100644 > --- a/net/9p/trans_virtio.c > +++ b/net/9p/trans_virtio.c > @@ -577,6 +577,10 @@ static int p9_virtio_probe(struct virtio_device *vdev) > mutex_lock(_9p_lock); > list_add_tail(>chan_list, _chan_list); > mutex_unlock(_9p_lock); > + > + /* Let udev rules use the new mount_tag attribute. */ > + kobject_uevent(&(vdev->dev.kobj), KOBJ_CHANGE); Ick, this is due to the sysfs file being added to the device after udev was told the device was present. I'm working on cleaning all of this up, to keep stuff like this from happening in the first place, by creating all of the needed files before userspace is told about the object, but it's a long slog, and will take a year or so to get it all right, the first pieces of this are going to be showing up in 3.12 or .13 at the earliest. For now, I have no objection to this patch at all, especially as it solves the problem for you. Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
That sounds like an issue with specific preemption policies. Mike Galbraith wrote: >On Sat, 2013-08-10 at 21:27 -0700, H. Peter Anvin wrote: >> On 08/10/2013 09:17 PM, Mike Galbraith wrote: >> >> >> >> Do you have any quantification of "munches throughput?" It seems >odd >> >> that it would be worse than polling for preempt all over the >kernel, but >> >> perhaps the additional locking is what costs. >> > >> > I hadn't compared in ages, so made some fresh samples. >> > >> > Q6600 3.11-rc4 >> > >> > vmark >> > voluntary 169808 155826 154741 1.000 >> > preempt 149354 124016 128436 .836 >> > >> > That should be ~worst case, it hates preemption. >> > >> > tbench 8 >> > voluntary1027.961028.761044.60 1.000 >> > preempt 929.06 935.01 928.64 .900 >> > >> > hackbench -l 1 >> > voluntary 23.146 23.124 23.230 1.000 >> > preempt 25.065 24.633 24.789 1.071 >> > >> > kbuild vmlinux >> > voluntary 3m44.842s 3m42.975s 3m42.954s 1.000 >> > preempt3m46.141s 3m45.835s 3m45.953s 1.010 >> > >> > Compute load comparisons are boring 'course. >> > >> >> I presume voluntary is indistinguishable from no preemption at all? > >No, all preemption options produce performance deltas. > >> Either way, that is definitely a reproducible test case, so if >someone >> is willing to take on optimizing preemption they can use vmark as the >> litmus test. It would be really awesome if we genuinely could get >the >> cost of preemption down to where it just doesn't matter. > >You have to eat more scheduler cycles, that's what PREEMPT does for a >living. Release a lock, wham. > >-Mike -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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] 9p: send uevent after adding/removing mount_tag attribute
This driver adds an attribute to the existing virtio device so a CHANGE event is required in order udev rules to make use of it. The ADD event happens before this driver is probed and unlike a more typical driver like a block device there isn't a higher level device to watch for. Signed-off-by: Michael Marineau --- net/9p/trans_virtio.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c index e1c26b1..990afab 100644 --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -577,6 +577,10 @@ static int p9_virtio_probe(struct virtio_device *vdev) mutex_lock(_9p_lock); list_add_tail(>chan_list, _chan_list); mutex_unlock(_9p_lock); + + /* Let udev rules use the new mount_tag attribute. */ + kobject_uevent(&(vdev->dev.kobj), KOBJ_CHANGE); + return 0; out_free_tag: @@ -654,6 +658,7 @@ static void p9_virtio_remove(struct virtio_device *vdev) list_del(>chan_list); mutex_unlock(_9p_lock); sysfs_remove_file(&(vdev->dev.kobj), _attr_mount_tag.attr); + kobject_uevent(&(vdev->dev.kobj), KOBJ_CHANGE); kfree(chan->tag); kfree(chan->vc_wq); kfree(chan); -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
On Sat, 2013-08-10 at 21:27 -0700, H. Peter Anvin wrote: > On 08/10/2013 09:17 PM, Mike Galbraith wrote: > >> > >> Do you have any quantification of "munches throughput?" It seems odd > >> that it would be worse than polling for preempt all over the kernel, but > >> perhaps the additional locking is what costs. > > > > I hadn't compared in ages, so made some fresh samples. > > > > Q6600 3.11-rc4 > > > > vmark > > voluntary 169808 155826 154741 1.000 > > preempt 149354 124016 128436 .836 > > > > That should be ~worst case, it hates preemption. > > > > tbench 8 > > voluntary1027.961028.761044.60 1.000 > > preempt 929.06 935.01 928.64 .900 > > > > hackbench -l 1 > > voluntary 23.146 23.124 23.230 1.000 > > preempt 25.065 24.633 24.789 1.071 > > > > kbuild vmlinux > > voluntary 3m44.842s 3m42.975s 3m42.954s 1.000 > > preempt3m46.141s 3m45.835s 3m45.953s 1.010 > > > > Compute load comparisons are boring 'course. > > > > I presume voluntary is indistinguishable from no preemption at all? No, all preemption options produce performance deltas. > Either way, that is definitely a reproducible test case, so if someone > is willing to take on optimizing preemption they can use vmark as the > litmus test. It would be really awesome if we genuinely could get the > cost of preemption down to where it just doesn't matter. You have to eat more scheduler cycles, that's what PREEMPT does for a living. Release a lock, wham. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
On 08/10/2013 09:17 PM, Mike Galbraith wrote: >> >> Do you have any quantification of "munches throughput?" It seems odd >> that it would be worse than polling for preempt all over the kernel, but >> perhaps the additional locking is what costs. > > I hadn't compared in ages, so made some fresh samples. > > Q6600 3.11-rc4 > > vmark > voluntary 169808 155826 154741 1.000 > preempt 149354 124016 128436 .836 > > That should be ~worst case, it hates preemption. > > tbench 8 > voluntary1027.961028.761044.60 1.000 > preempt 929.06 935.01 928.64 .900 > > hackbench -l 1 > voluntary 23.146 23.124 23.230 1.000 > preempt 25.065 24.633 24.789 1.071 > > kbuild vmlinux > voluntary 3m44.842s 3m42.975s 3m42.954s 1.000 > preempt3m46.141s 3m45.835s 3m45.953s 1.010 > > Compute load comparisons are boring 'course. > I presume voluntary is indistinguishable from no preemption at all? Either way, that is definitely a reproducible test case, so if someone is willing to take on optimizing preemption they can use vmark as the litmus test. It would be really awesome if we genuinely could get the cost of preemption down to where it just doesn't matter. -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: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
On Sat, 2013-08-10 at 09:09 -0700, H. Peter Anvin wrote: > On 08/09/2013 10:55 PM, Mike Galbraith wrote: > >> > >> Now, here is a bigger question: shouldn't we be deprecating/getting rid > >> of PREEMPT_VOUNTARY in favor of PREEMPT? > > > > I sure hope not, PREEMPT munches throughput. If you need PREEMPT, seems > > to me what you _really_ need is PREEMPT_RT (the real deal), so > > eventually depreciating PREEMPT makes more sense to me. > > > > Do you have any quantification of "munches throughput?" It seems odd > that it would be worse than polling for preempt all over the kernel, but > perhaps the additional locking is what costs. I hadn't compared in ages, so made some fresh samples. Q6600 3.11-rc4 vmark voluntary 169808 155826 154741 1.000 preempt 149354 124016 128436 .836 That should be ~worst case, it hates preemption. tbench 8 voluntary1027.961028.761044.60 1.000 preempt 929.06 935.01 928.64 .900 hackbench -l 1 voluntary 23.146 23.124 23.230 1.000 preempt 25.065 24.633 24.789 1.071 kbuild vmlinux voluntary 3m44.842s 3m42.975s 3m42.954s 1.000 preempt3m46.141s 3m45.835s 3m45.953s 1.010 Compute load comparisons are boring 'course. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Loan Offer @ 2% ineterest rate. Email more details:
We give out all kinds of loans,If interested do contact us through email lucasmooremultifinanc...@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/
£1.5 million British Pounds
My wife and I won the Euro Millions Lottery of £41 Million British Pounds and we have decided to donate £1.5 million British Pounds each to 10 individuals worldwide as part of our own charity project. To verify,please see our interview by visiting the web page below: http://www.dailymail.co.uk/news/article-2091124/EuroMillions-winners-Gareth-Catherine-Bull-scoop-41MILLION-lotto-jackpot.html Your email address was among the emails which were submitted to us by the Google, Inc as a web user; if you have received our email please, kindly send us the below details so that we can transfer your £1,500,000.00 pounds in your name or direct our bank to effect the transfer of the funds to your operational bank account in your country, congratulations. Full Name: Mobile No: Age: Country: Send your response to (mr.garethb...@foxmail.com) Best Regards, Gareth & Catherine Bull
Re: [ 000/102] 3.10.6-stable review
On Sat, Aug 10, 2013 at 10:07:08PM +, Shuah Khan wrote: > On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote: > > On Fri, Aug 09, 2013 at 02:42:24PM +, Shuah Khan wrote: > >> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote: > >>> This is the start of the stable review cycle for the 3.10.6 release. > >>> There are 102 patches in this series, all will be posted as a response > >>> to this one. If anyone has any issues with these being applied, please > >>> let me know. > >>> > >>> Responses should be made by Sun Aug 11 01:46:31 UTC 2013. > >>> Anything received after that time might be too late. > >>> > >>> The whole patch series can be found in one patch at: > >>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz > >>> and the diffstat can be found below. > >>> > >>> thanks, > >>> > >>> greg k-h > >>> > > > > Patches applied to 3.0.89, 3.4.56 and 3.10.5 > > Compiled and booted on the following systems: > > Samsung Series 9 900X4C Intel Corei5: > (3.4.57-rc1, 3.10.6-rc1) > HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: > (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1) > > dmesgs for all releases look good. No regressions compared to the > previous dmesgs for each of these releases. dmesg emerg, crit, alert, > err are clean. No regressions in warn. Thanks for testing all of these and letting me know. 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 v2 4/4] mtd: gpmi: update the ecc step size for mtd_info{}
于 2013年08月10日 03:53, Brian Norris 写道: The right way seems to be to avoid nand_scan() directly but instead to > use nand_scan_ident() and nand_scan_tail() separately (that's what > they're exported for) so that you can initialize any geometry-related > options before nand_scan_tail() does the last steps. i agree with you. I will create a v3 version tomorrow when i back to office. thanks for the review. Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 02/28] genirq: Add irq_alloc_reserved_desc()
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.
The reasons for not allocating them during reserving:
1. only several pins of one ioapic are used, allocate for all pins, will
waste memory for not used pins.
2. allocate later when is needed could make sure irq_desc is allocated
on local node ram, as dev->node is set at that point.
-v2: update changelog by adding reasons, requested by Konrad.
-v3: according to tglx:
separate core code change with arch code change.
change function name to irq_alloc_reserved_desc.
kill __irq_is_reserved().
remove not need exports.
according to Sebastian:
spare one comments by put two functions together.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
include/linux/irq.h | 3 +++
kernel/irq/irqdesc.c | 23 +++
2 files changed, 26 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 8c46cb2..b998ea7 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -592,10 +592,13 @@ static inline u32 irq_get_trigger_type(unsigned int irq)
int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
+int __irq_alloc_reserved_desc(int at, int node, struct module *owner);
/* use macros to avoid needing export.h for THIS_MODULE */
#define irq_alloc_descs(irq, from, cnt, node) \
__irq_alloc_descs(irq, from, cnt, node, THIS_MODULE)
+#define irq_alloc_reserved_desc_at(at, node) \
+ __irq_alloc_reserved_desc(at, node, THIS_MODULE)
#define irq_alloc_desc(node) \
irq_alloc_descs(-1, 0, 1, node)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index a151db6..1166545 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -410,6 +410,29 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned int
cnt, int node,
EXPORT_SYMBOL_GPL(__irq_alloc_descs);
/**
+ * __irq_alloc_reserved_desc - allocate irq descriptor for irq that is already
reserved
+ * @irq: Allocate for specific irq number if irq >= 0
+ * @node: Preferred node on which the irq descriptor should be allocated
+ * @owner: Owning module (can be NULL)
+ *
+ * Returns the irq number or error code
+ */
+int __ref __irq_alloc_reserved_desc(int irq, int node, struct module *owner)
+{
+ mutex_lock(_irq_lock);
+ if (!test_bit(irq, allocated_irqs)) {
+ mutex_unlock(_irq_lock);
+ return -EINVAL;
+ }
+ mutex_unlock(_irq_lock);
+
+ if (irq_to_desc(irq))
+ return irq;
+
+ return alloc_descs(irq, 1, node, owner);
+}
+
+/**
* irq_reserve_irqs - mark irqs allocated
* @from: mark from irq number
* @cnt: number of irqs to mark
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 10/28] iommu, irq: Allocate irq_desc for dmar_msi with local node
iommu irq's irq_desc should be on local node ram.
Fix the return value checking problem.
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
here only check !irq, so need to change it to use create_irq_nr instead.
-v2: According to Sebastian, add cc to stable.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Donald Dutile
Acked-by: Donald Dutile
Cc: Sebastian Andrzej Siewior
Cc: sta...@vger.kernel.org
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 785675a..db41e36 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1277,7 +1277,7 @@ int dmar_set_interrupt(struct intel_iommu *iommu)
if (iommu->irq)
return 0;
- irq = create_irq();
+ irq = create_irq_nr(0, iommu->node);
if (!irq) {
pr_err("IOMMU: no free vectors\n");
return -EINVAL;
--
1.8.1.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 07/28] x86, irq: Show MSI-X in /proc/interrupt
Now MSI-X is shown as MSI in /proc/interrupt.
We could use new added irq_print_chip() interface to append -X for MSI-X.
After this patch, we will have PCI-MSI-X-edge IR-PCI-MSI-X-edge for MSI-X
instead of PCI-MSI-edge IR-PCI-MSI-edge in the /proc/interrupt.
-v2: do not need to check if msi_desc is null in msi_irq_print_chip().
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 7 +++
drivers/iommu/irq_remapping.c | 5 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 119fdf8..cf320fb 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3087,6 +3087,12 @@ msi_set_affinity(struct irq_data *data, const struct
cpumask *mask, bool force)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static void msi_irq_print_chip(struct irq_data *data, struct seq_file *p)
+{
+ seq_printf(p, " %s%s", data->chip->name,
+ data->msi_desc->msi_attrib.is_msix ? "-X" : "");
+}
+
/*
* IRQ Chip for MSI PCI/PCI-X/PCI-Express Devices,
* which implement the MSI or MSI-X Capability Structure.
@@ -3098,6 +3104,7 @@ struct irq_chip msi_chip = {
.irq_ack= ack_apic_edge,
.irq_set_affinity = msi_set_affinity,
.irq_retrigger = ioapic_retrigger_irq,
+ .irq_print_chip = msi_irq_print_chip,
};
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 8e4e3af..6893d75 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -372,7 +372,10 @@ static void ir_ack_apic_level(struct irq_data *data)
static void ir_print_prefix(struct irq_data *data, struct seq_file *p)
{
- seq_printf(p, " IR-%s", data->chip->name);
+ seq_printf(p, " IR-%s%s", data->chip->name,
+ data->msi_desc ?
+(data->msi_desc->msi_attrib.is_msix ? "-X" : "")
+: "");
}
static void __init irq_remap_modify_chip_defaults(struct irq_chip *chip)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 07/28] x86, irq: Show MSI-X in /proc/interrupt
Now MSI-X is shown as MSI in /proc/interrupt.
We could use new added irq_print_chip() interface to append -X for MSI-X.
After this patch, we will have PCI-MSI-X-edge IR-PCI-MSI-X-edge for MSI-X
instead of PCI-MSI-edge IR-PCI-MSI-edge in the /proc/interrupt.
-v2: do not need to check if msi_desc is null in msi_irq_print_chip().
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 7 +++
drivers/iommu/irq_remapping.c | 5 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 119fdf8..cf320fb 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3087,6 +3087,12 @@ msi_set_affinity(struct irq_data *data, const struct
cpumask *mask, bool force)
return IRQ_SET_MASK_OK_NOCOPY;
}
+static void msi_irq_print_chip(struct irq_data *data, struct seq_file *p)
+{
+ seq_printf(p, " %s%s", data->chip->name,
+ data->msi_desc->msi_attrib.is_msix ? "-X" : "");
+}
+
/*
* IRQ Chip for MSI PCI/PCI-X/PCI-Express Devices,
* which implement the MSI or MSI-X Capability Structure.
@@ -3098,6 +3104,7 @@ struct irq_chip msi_chip = {
.irq_ack= ack_apic_edge,
.irq_set_affinity = msi_set_affinity,
.irq_retrigger = ioapic_retrigger_irq,
+ .irq_print_chip = msi_irq_print_chip,
};
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 8e4e3af..6893d75 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -372,7 +372,10 @@ static void ir_ack_apic_level(struct irq_data *data)
static void ir_print_prefix(struct irq_data *data, struct seq_file *p)
{
- seq_printf(p, " IR-%s", data->chip->name);
+ seq_printf(p, " IR-%s%s", data->chip->name,
+ data->msi_desc ?
+(data->msi_desc->msi_attrib.is_msix ? "-X" : "")
+: "");
}
static void __init irq_remap_modify_chip_defaults(struct irq_chip *chip)
--
1.8.1.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 04/28] x86, irqi: Change irq_remap_modify_chip_defaults() to static
Change irq_remap_modify_chip_defaults() to static, as we have no
outside user.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/irq_remapping.h | 6 --
drivers/iommu/irq_remapping.c| 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index d806b22..606f42e 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -56,8 +56,6 @@ extern bool setup_remapped_irq(int irq,
struct irq_cfg *cfg,
struct irq_chip *chip);
-void irq_remap_modify_chip_defaults(struct irq_chip *chip);
-
#else /* CONFIG_IRQ_REMAP */
static inline void setup_irq_remapping_ops(void) { }
@@ -91,10 +89,6 @@ static inline void panic_if_irq_remap(const char *msg)
{
}
-static inline void irq_remap_modify_chip_defaults(struct irq_chip *chip)
-{
-}
-
static inline bool setup_remapped_irq(int irq,
struct irq_cfg *cfg,
struct irq_chip *chip)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 39f81ae..85ae2cf 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -375,7 +375,7 @@ static void ir_print_prefix(struct irq_data *data, struct
seq_file *p)
seq_printf(p, " IR-%s", data->chip->name);
}
-void irq_remap_modify_chip_defaults(struct irq_chip *chip)
+static void irq_remap_modify_chip_defaults(struct irq_chip *chip)
{
chip->irq_print_chip = ir_print_prefix;
chip->irq_ack = ir_ack_apic_edge;
--
1.8.1.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 02/28] genirq: Add irq_alloc_reserved_desc()
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.
The reasons for not allocating them during reserving:
1. only several pins of one ioapic are used, allocate for all pins, will
waste memory for not used pins.
2. allocate later when is needed could make sure irq_desc is allocated
on local node ram, as dev->node is set at that point.
-v2: update changelog by adding reasons, requested by Konrad.
-v3: according to tglx:
separate core code change with arch code change.
change function name to irq_alloc_reserved_desc.
kill __irq_is_reserved().
remove not need exports.
according to Sebastian:
spare one comments by put two functions together.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
include/linux/irq.h | 3 +++
kernel/irq/irqdesc.c | 23 +++
2 files changed, 26 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 8c46cb2..b998ea7 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -592,10 +592,13 @@ static inline u32 irq_get_trigger_type(unsigned int irq)
int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
+int __irq_alloc_reserved_desc(int at, int node, struct module *owner);
/* use macros to avoid needing export.h for THIS_MODULE */
#define irq_alloc_descs(irq, from, cnt, node) \
__irq_alloc_descs(irq, from, cnt, node, THIS_MODULE)
+#define irq_alloc_reserved_desc_at(at, node) \
+ __irq_alloc_reserved_desc(at, node, THIS_MODULE)
#define irq_alloc_desc(node) \
irq_alloc_descs(-1, 0, 1, node)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index a151db6..1166545 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -410,6 +410,29 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned int
cnt, int node,
EXPORT_SYMBOL_GPL(__irq_alloc_descs);
/**
+ * __irq_alloc_reserved_desc - allocate irq descriptor for irq that is already
reserved
+ * @irq: Allocate for specific irq number if irq >= 0
+ * @node: Preferred node on which the irq descriptor should be allocated
+ * @owner: Owning module (can be NULL)
+ *
+ * Returns the irq number or error code
+ */
+int __ref __irq_alloc_reserved_desc(int irq, int node, struct module *owner)
+{
+ mutex_lock(_irq_lock);
+ if (!test_bit(irq, allocated_irqs)) {
+ mutex_unlock(_irq_lock);
+ return -EINVAL;
+ }
+ mutex_unlock(_irq_lock);
+
+ if (irq_to_desc(irq))
+ return irq;
+
+ return alloc_descs(irq, 1, node, owner);
+}
+
+/**
* irq_reserve_irqs - mark irqs allocated
* @from: mark from irq number
* @cnt: number of irqs to mark
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 09/28] ia64, irq: Add dummy create_irq_nr()
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
Will use it to fix one return value checking for dmar_msi irq.
Signed-off-by: Yinghai Lu
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
Cc: sta...@vger.kernel.org
---
arch/ia64/kernel/irq_ia64.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/ia64/kernel/irq_ia64.c b/arch/ia64/kernel/irq_ia64.c
index 1034884..38e46df 100644
--- a/arch/ia64/kernel/irq_ia64.c
+++ b/arch/ia64/kernel/irq_ia64.c
@@ -429,6 +429,16 @@ int create_irq(void)
return irq;
}
+unsigned int create_irq_nr(unsigned int from, int node)
+{
+ int irq = create_irq();
+
+ if (irq < 0)
+ irq = 0;
+
+ return irq;
+}
+
void destroy_irq(unsigned int irq)
{
dynamic_irq_cleanup(irq);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 11/28] x86, irq: Kill create_irq()
create_irq() will return -1 when failing to allocate.
create_irq_nr() will return 0 when failing to allocate.
It only causes confusion.
Now we have no user for create_irq(), so remove create_irq() for x86.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 47add1a..ccfb1d3 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2968,21 +2968,6 @@ unsigned int create_irq_nr(unsigned int from, int node)
return __create_irqs(from, 1, node);
}
-int create_irq(void)
-{
- int node = cpu_to_node(0);
- unsigned int irq_want;
- int irq;
-
- irq_want = nr_irqs_gsi;
- irq = create_irq_nr(irq_want, node);
-
- if (irq == 0)
- irq = -1;
-
- return irq;
-}
-
void destroy_irq(unsigned int irq)
{
struct irq_cfg *cfg = irq_get_chip_data(irq);
--
1.8.1.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 09/28] ia64, irq: Add dummy create_irq_nr()
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
Will use it to fix one return value checking for dmar_msi irq.
Signed-off-by: Yinghai Lu
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
Cc: sta...@vger.kernel.org
---
arch/ia64/kernel/irq_ia64.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/ia64/kernel/irq_ia64.c b/arch/ia64/kernel/irq_ia64.c
index 1034884..38e46df 100644
--- a/arch/ia64/kernel/irq_ia64.c
+++ b/arch/ia64/kernel/irq_ia64.c
@@ -429,6 +429,16 @@ int create_irq(void)
return irq;
}
+unsigned int create_irq_nr(unsigned int from, int node)
+{
+ int irq = create_irq();
+
+ if (irq < 0)
+ irq = 0;
+
+ return irq;
+}
+
void destroy_irq(unsigned int irq)
{
dynamic_irq_cleanup(irq);
--
1.8.1.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 04/28] x86, irq: Change irq_remap_modify_chip_defaults() to static
Change irq_remap_modify_chip_defaults() to static, as we have no
outside user.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/irq_remapping.h | 6 --
drivers/iommu/irq_remapping.c| 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index d806b22..606f42e 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -56,8 +56,6 @@ extern bool setup_remapped_irq(int irq,
struct irq_cfg *cfg,
struct irq_chip *chip);
-void irq_remap_modify_chip_defaults(struct irq_chip *chip);
-
#else /* CONFIG_IRQ_REMAP */
static inline void setup_irq_remapping_ops(void) { }
@@ -91,10 +89,6 @@ static inline void panic_if_irq_remap(const char *msg)
{
}
-static inline void irq_remap_modify_chip_defaults(struct irq_chip *chip)
-{
-}
-
static inline bool setup_remapped_irq(int irq,
struct irq_cfg *cfg,
struct irq_chip *chip)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 39f81ae..85ae2cf 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -375,7 +375,7 @@ static void ir_print_prefix(struct irq_data *data, struct
seq_file *p)
seq_printf(p, " IR-%s", data->chip->name);
}
-void irq_remap_modify_chip_defaults(struct irq_chip *chip)
+static void irq_remap_modify_chip_defaults(struct irq_chip *chip)
{
chip->irq_print_chip = ir_print_prefix;
chip->irq_ack = ir_ack_apic_edge;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 04/28] x86, irq: Change irq_remap_modify_chip_defaults() to static
Change irq_remap_modify_chip_defaults() to static, as we have no
outside user.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/irq_remapping.h | 6 --
drivers/iommu/irq_remapping.c| 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index d806b22..606f42e 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -56,8 +56,6 @@ extern bool setup_remapped_irq(int irq,
struct irq_cfg *cfg,
struct irq_chip *chip);
-void irq_remap_modify_chip_defaults(struct irq_chip *chip);
-
#else /* CONFIG_IRQ_REMAP */
static inline void setup_irq_remapping_ops(void) { }
@@ -91,10 +89,6 @@ static inline void panic_if_irq_remap(const char *msg)
{
}
-static inline void irq_remap_modify_chip_defaults(struct irq_chip *chip)
-{
-}
-
static inline bool setup_remapped_irq(int irq,
struct irq_cfg *cfg,
struct irq_chip *chip)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 39f81ae..85ae2cf 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -375,7 +375,7 @@ static void ir_print_prefix(struct irq_data *data, struct
seq_file *p)
seq_printf(p, " IR-%s", data->chip->name);
}
-void irq_remap_modify_chip_defaults(struct irq_chip *chip)
+static void irq_remap_modify_chip_defaults(struct irq_chip *chip)
{
chip->irq_print_chip = ir_print_prefix;
chip->irq_ack = ir_ack_apic_edge;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 06/28] x86, irq: Show MSI-X clearly in debug message
Print out exact MSI or MSI-X instead of MSI/MSI-X. Signed-off-by: Yinghai Lu Cc: Joerg Roedel Cc: Konrad Rzeszutek Wilk Cc: Sebastian Andrzej Siewior --- arch/x86/kernel/apic/io_apic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index eda56ad..119fdf8 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -3125,7 +3125,8 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, irq_set_chip_and_handler_name(irq, chip, handle_edge_irq, "edge"); - dev_printk(KERN_DEBUG, >dev, "irq %d for MSI/MSI-X\n", irq); + dev_printk(KERN_DEBUG, >dev, "irq %d for MSI%s\n", irq, +msidesc->msi_attrib.is_msix ? "-X" : ""); return 0; } -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 14/28] x86, irq: Move down arch_early_irq_init()
Change position only.
Prepare to update arch_early_irq_init() that needs to call some static
functions.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 89 +-
1 file changed, 44 insertions(+), 45 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index c883da9..18b123b 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -185,51 +185,6 @@ static struct irq_pin_list *alloc_irq_pin_list(int node)
return kzalloc_node(sizeof(struct irq_pin_list), GFP_KERNEL, node);
}
-
-/* irq_cfg is indexed by the sum of all RTEs in all I/O APICs. */
-static struct irq_cfg irq_cfgx[NR_IRQS_LEGACY];
-
-int __init arch_early_irq_init(void)
-{
- struct irq_cfg *cfg;
- int count, node, i;
-
- if (!legacy_pic->nr_legacy_irqs)
- io_apic_irqs = ~0UL;
-
- for (i = 0; i < nr_ioapics; i++) {
- ioapics[i].saved_registers =
- kzalloc(sizeof(struct IO_APIC_route_entry) *
- ioapics[i].nr_registers, GFP_KERNEL);
- if (!ioapics[i].saved_registers)
- pr_err("IOAPIC %d: suspend/resume impossible!\n", i);
- }
-
- cfg = irq_cfgx;
- count = ARRAY_SIZE(irq_cfgx);
- node = cpu_to_node(0);
-
- /* Make sure the legacy interrupts are marked in the bitmap */
- irq_reserve_irqs(0, legacy_pic->nr_legacy_irqs);
-
- for (i = 0; i < count; i++) {
- INIT_LIST_HEAD([i].irq_2_pin);
- irq_set_chip_data(i, [i]);
- zalloc_cpumask_var_node([i].domain, GFP_KERNEL, node);
- zalloc_cpumask_var_node([i].old_domain, GFP_KERNEL, node);
- /*
-* For legacy IRQ's, start with assigning irq0 to irq15 to
-* IRQ0_VECTOR to IRQ15_VECTOR for all cpu's.
-*/
- if (i < legacy_pic->nr_legacy_irqs) {
- cfg[i].vector = IRQ0_VECTOR + i;
- cpumask_setall(cfg[i].domain);
- }
- }
-
- return 0;
-}
-
static struct irq_cfg *irq_cfg(unsigned int irq)
{
return irq_get_chip_data(irq);
@@ -325,6 +280,50 @@ static struct irq_cfg
*alloc_reserved_irq_and_cfg_at(unsigned int at, int node)
return alloc_irq_and_cfg_at(at, node);
}
+/* irq_cfg is indexed by the sum of all RTEs in all I/O APICs. */
+static struct irq_cfg irq_cfgx[NR_IRQS_LEGACY];
+
+int __init arch_early_irq_init(void)
+{
+ struct irq_cfg *cfg;
+ int count, node, i;
+
+ if (!legacy_pic->nr_legacy_irqs)
+ io_apic_irqs = ~0UL;
+
+ for (i = 0; i < nr_ioapics; i++) {
+ ioapics[i].saved_registers =
+ kzalloc(sizeof(struct IO_APIC_route_entry) *
+ ioapics[i].nr_registers, GFP_KERNEL);
+ if (!ioapics[i].saved_registers)
+ pr_err("IOAPIC %d: suspend/resume impossible!\n", i);
+ }
+
+ cfg = irq_cfgx;
+ count = ARRAY_SIZE(irq_cfgx);
+ node = cpu_to_node(0);
+
+ /* Make sure the legacy interrupts are marked in the bitmap */
+ irq_reserve_irqs(0, legacy_pic->nr_legacy_irqs);
+
+ for (i = 0; i < count; i++) {
+ INIT_LIST_HEAD([i].irq_2_pin);
+ irq_set_chip_data(i, [i]);
+ zalloc_cpumask_var_node([i].domain, GFP_KERNEL, node);
+ zalloc_cpumask_var_node([i].old_domain, GFP_KERNEL, node);
+ /*
+* For legacy IRQ's, start with assigning irq0 to irq15 to
+* IRQ0_VECTOR to IRQ15_VECTOR for all cpu's.
+*/
+ if (i < legacy_pic->nr_legacy_irqs) {
+ cfg[i].vector = IRQ0_VECTOR + i;
+ cpumask_setall(cfg[i].domain);
+ }
+ }
+
+ return 0;
+}
+
struct io_apic {
unsigned int index;
unsigned int unused[3];
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 19/28] x86, irq: Add for_each_ioapic helper
For hotadd and hotremove ioapic controller, we leave blank
slots in ioapics array.
So we can not use for (i=...) to loop them any more.
Introdue ioapics_mask bitmap to track used ioapics, and use
for_each_ioapic to loop them.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
Cc: Grant Likely
Cc: Paul Gortmaker
Cc: Andy Lutomirski
Cc: io...@lists.linux-foundation.org
---
arch/x86/include/asm/io_apic.h | 6
arch/x86/kernel/apic/io_apic.c | 64 -
arch/x86/kernel/devicetree.c| 2 +-
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/intel_irq_remapping.c | 2 +-
5 files changed, 43 insertions(+), 33 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 02ac411..a25dcf1 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -105,6 +105,12 @@ struct IR_IO_APIC_route_entry {
* # of IO-APICs and # of IRQ routing registers
*/
extern int nr_ioapics;
+extern DECLARE_BITMAP(ioapics_mask, MAX_IO_APICS);
+
+#define for_each_ioapic(i) \
+ for ((i) = -1; \
+ (i) = find_next_bit(ioapics_mask, MAX_IO_APICS, (i)+1), \
+ (i) < MAX_IO_APICS;)
extern int mpc_ioapic_id(int ioapic);
extern unsigned int mpc_ioapic_addr(int ioapic);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 8d087f1..b026cc7 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -93,6 +93,8 @@ static struct ioapic {
DECLARE_BITMAP(pin_programmed, MP_MAX_IOAPIC_PIN + 1);
} ioapics[MAX_IO_APICS];
+DECLARE_BITMAP(ioapics_mask, MAX_IO_APICS);
+
#define mpc_ioapic_ver(ioapic_idx) ioapics[ioapic_idx].mp_config.apicver
int mpc_ioapic_id(int ioapic_idx)
@@ -344,10 +346,10 @@ int __init arch_early_irq_init(void)
if (!legacy_pic->nr_legacy_irqs)
io_apic_irqs = ~0UL;
- for (i = 0; i < nr_ioapics; i++)
+ for_each_ioapic(i)
alloc_ioapic_saved_registers(i);
- for (i = 0; i < nr_ioapics; i++)
+ for_each_ioapic(i)
reserve_ioapic_gsi_irq_base(i);
reserve_ioapic_gsi_irq_extra();
@@ -715,7 +717,7 @@ static void clear_IO_APIC (void)
{
int apic, pin;
- for (apic = 0; apic < nr_ioapics; apic++)
+ for_each_ioapic(apic)
for (pin = 0; pin < ioapics[apic].nr_registers; pin++)
clear_IO_APIC_pin(apic, pin);
}
@@ -766,7 +768,7 @@ int save_ioapic_entries(void)
int apic, pin;
int err = 0;
- for (apic = 0; apic < nr_ioapics; apic++) {
+ for_each_ioapic(apic) {
if (!ioapics[apic].saved_registers) {
err = -ENOMEM;
continue;
@@ -787,7 +789,7 @@ void mask_ioapic_entries(void)
{
int apic, pin;
- for (apic = 0; apic < nr_ioapics; apic++) {
+ for_each_ioapic(apic) {
if (!ioapics[apic].saved_registers)
continue;
@@ -810,7 +812,7 @@ int restore_ioapic_entries(void)
{
int apic, pin;
- for (apic = 0; apic < nr_ioapics; apic++) {
+ for_each_ioapic(apic) {
if (!ioapics[apic].saved_registers)
continue;
@@ -873,7 +875,7 @@ static int __init find_isa_irq_apic(int irq, int type)
if (i < mp_irq_entries) {
int ioapic_idx;
- for (ioapic_idx = 0; ioapic_idx < nr_ioapics; ioapic_idx++)
+ for_each_ioapic(ioapic_idx)
if (mpc_ioapic_id(ioapic_idx) == mp_irqs[i].dstapic)
return ioapic_idx;
}
@@ -1095,7 +1097,7 @@ int IO_APIC_get_PCI_irq_vector(int bus, int slot, int pin,
for (i = 0; i < mp_irq_entries; i++) {
int lbus = mp_irqs[i].srcbus;
- for (ioapic_idx = 0; ioapic_idx < nr_ioapics; ioapic_idx++)
+ for_each_ioapic(ioapic_idx)
if (mpc_ioapic_id(ioapic_idx) == mp_irqs[i].dstapic ||
mp_irqs[i].dstapic == MP_APIC_ALL)
break;
@@ -1316,7 +1318,7 @@ static inline int IO_APIC_irq_trigger(int irq)
{
int apic, idx, pin;
- for (apic = 0; apic < nr_ioapics; apic++) {
+ for_each_ioapic(apic) {
for (pin = 0; pin < ioapics[apic].nr_registers; pin++) {
idx = find_irq_entry(apic, pin, mp_INT);
if ((idx != -1) && (irq == pin_2_irq(idx, apic, pin)))
@@ -1472,7 +1474,7 @@ static void __init setup_IO_APIC_irqs(void)
apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n");
- for (ioapic_idx = 0; ioapic_idx < nr_ioapics; ioapic_idx++)
+ for_each_ioapic(ioapic_idx)
[PATCH v4 27/28] PCI, x86, ACPI: Enable ioapic hotplug support with acpi host bridge.
We need to have ioapic setup before normal pci drivers.
otherwise other pci driver can not setup irq.
So we should not treat them as normal pci devices.
Also we will need to support ioapic hotplug without pci device around.
We need to call ioapic add/remove during host-bridge add/remove.
Signed-off-by: Yinghai Lu
---
drivers/acpi/pci_root.c | 4 ++
drivers/pci/ioapic.c | 147 ++-
include/linux/pci-acpi.h | 8 +++
3 files changed, 106 insertions(+), 53 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 5917839..7577175 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -532,6 +532,8 @@ static int acpi_pci_root_add(struct acpi_device *device,
pci_enable_bridges(root->bus);
}
+ acpi_pci_ioapic_add(root);
+
pci_bus_add_devices(root->bus);
return 1;
@@ -546,6 +548,8 @@ static void acpi_pci_root_remove(struct acpi_device *device)
pci_stop_root_bus(root->bus);
+ acpi_pci_ioapic_remove(root);
+
device_set_run_wake(root->bus->bridge, false);
pci_acpi_remove_bus_pm_notifier(device);
diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
index 7d6b157..60351b2 100644
--- a/drivers/pci/ioapic.c
+++ b/drivers/pci/ioapic.c
@@ -22,101 +22,142 @@
#include
#include
-struct ioapic {
- acpi_handle handle;
+struct acpi_pci_ioapic {
+ acpi_handle root_handle;
u32 gsi_base;
+ struct pci_dev *pdev;
+ struct list_head list;
};
-static int ioapic_probe(struct pci_dev *dev, const struct pci_device_id *ent)
+static LIST_HEAD(ioapic_list);
+static DEFINE_MUTEX(ioapic_list_lock);
+
+static void handle_ioapic_add(acpi_handle handle, struct pci_dev **pdev,
+u32 *pgsi_base)
{
- acpi_handle handle;
acpi_status status;
unsigned long long gsb;
- struct ioapic *ioapic;
+ struct pci_dev *dev;
+ u32 gsi_base;
int ret;
char *type;
- struct resource *res;
+ struct resource r;
+ struct resource *res =
+ char objname[64];
+ struct acpi_buffer buffer = {sizeof(objname), objname};
- handle = DEVICE_ACPI_HANDLE(>dev);
- if (!handle)
- return -EINVAL;
+ *pdev = NULL;
+ *pgsi_base = 0;
status = acpi_evaluate_integer(handle, "_GSB", NULL, );
- if (ACPI_FAILURE(status))
- return -EINVAL;
-
- /*
-* The previous code in acpiphp evaluated _MAT if _GSB failed, but
-* ACPI spec 4.0 sec 6.2.2 requires _GSB for hot-pluggable I/O APICs.
-*/
+ if (ACPI_FAILURE(status) || !gsb)
+ return;
- ioapic = kzalloc(sizeof(*ioapic), GFP_KERNEL);
- if (!ioapic)
- return -ENOMEM;
+ dev = acpi_get_pci_dev(handle);
+ if (!dev)
+ return;
- ioapic->handle = handle;
- ioapic->gsi_base = (u32) gsb;
+ acpi_get_name(handle, ACPI_FULL_PATHNAME, );
- if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
- type = "IOAPIC";
- else
- type = "IOxAPIC";
+ gsi_base = gsb;
+ type = "IOxAPIC";
ret = pci_enable_device(dev);
if (ret < 0)
- goto exit_free;
+ goto exit_put;
pci_set_master(dev);
+ if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
+ type = "IOAPIC";
+
if (pci_request_region(dev, 0, type))
goto exit_disable;
res = >resource[0];
- if (acpi_register_ioapic(ioapic->handle, res->start, ioapic->gsi_base))
+
+ if (acpi_register_ioapic(handle, res->start, gsi_base))
goto exit_release;
- pci_set_drvdata(dev, ioapic);
- dev_info(>dev, "%s at %pR, GSI %u\n", type, res, ioapic->gsi_base);
- return 0;
+ pr_info("%s %s %s at %pR, GSI %u\n",
+ dev_name(>dev), objname, type,
+ res, gsi_base);
+
+ *pdev = dev;
+ *pgsi_base = gsi_base;
+ return;
exit_release:
pci_release_region(dev, 0);
exit_disable:
pci_disable_device(dev);
-exit_free:
- kfree(ioapic);
- return -ENODEV;
+exit_put:
+ pci_dev_put(dev);
}
-static void ioapic_remove(struct pci_dev *dev)
+static void handle_ioapic_remove(acpi_handle handle, struct pci_dev *dev,
+ u32 gsi_base)
{
- struct ioapic *ioapic = pci_get_drvdata(dev);
+ acpi_unregister_ioapic(handle, gsi_base);
- acpi_unregister_ioapic(ioapic->handle, ioapic->gsi_base);
pci_release_region(dev, 0);
pci_disable_device(dev);
- kfree(ioapic);
+ pci_dev_put(dev);
}
+static acpi_status register_ioapic(acpi_handle handle, u32 lvl,
+ void *context, void **rv)
+{
+ acpi_handle root_handle = context;
+
[PATCH v4 08/28] x86, irq: Make dmar_msi/hpet_msi irq_chip name consistent
All others are using "-" instead of "_".
Change dmar_msi and hpet_msi to use "-".
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index cf320fb..47add1a 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3199,7 +3199,7 @@ dmar_msi_set_affinity(struct irq_data *data, const struct
cpumask *mask,
}
static struct irq_chip dmar_msi_type = {
- .name = "DMAR_MSI",
+ .name = "DMAR-MSI",
.irq_unmask = dmar_msi_unmask,
.irq_mask = dmar_msi_mask,
.irq_ack= ack_apic_edge,
@@ -3247,7 +3247,7 @@ static int hpet_msi_set_affinity(struct irq_data *data,
}
struct irq_chip hpet_msi_type = {
- .name = "HPET_MSI",
+ .name = "HPET-MSI",
.irq_unmask = hpet_msi_unmask,
.irq_mask = hpet_msi_mask,
.irq_ack = ack_apic_edge,
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 18/28] x86, irq: Add ioapic_gsi_to_irq
For hot add ioapic, irq_base is not equal to gsi_base.
We need a way to do mapping between gsi and irq.
Also remove irq_to_gsi() that is confusing, just use that array
directly as we only have one caller and it already check
input irq before use it.
Signed-off-by: Yinghai Lu
Cc: Pavel Machek
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/io_apic.h | 1 +
arch/x86/kernel/acpi/boot.c| 22 +-
arch/x86/kernel/apic/io_apic.c | 29 -
3 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 8181fd8..02ac411 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -180,6 +180,7 @@ struct mp_ioapic_gsi{
};
extern struct mp_ioapic_gsi mp_gsi_routing[];
extern u32 gsi_top;
+int ioapic_gsi_to_irq(u32 gsi);
int mp_find_ioapic(u32 gsi);
int mp_find_ioapic_pin(int ioapic, u32 gsi);
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 2627a81..5be15d1 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -112,6 +112,10 @@ static unsigned int gsi_to_irq(unsigned int gsi)
}
}
+#ifdef CONFIG_X86_IO_APIC
+ if (acpi_irq_model == ACPI_IRQ_MODEL_IOAPIC)
+ return ioapic_gsi_to_irq(gsi);
+#endif
/* Provide an identity mapping of gsi == irq
* except on truly weird platforms that have
* non isa irqs in the first 16 gsis.
@@ -124,22 +128,6 @@ static unsigned int gsi_to_irq(unsigned int gsi)
return irq;
}
-static u32 irq_to_gsi(int irq)
-{
- unsigned int gsi;
-
- if (irq < NR_IRQS_LEGACY)
- gsi = isa_irq_to_gsi[irq];
- else if (irq < gsi_top)
- gsi = irq;
- else if (irq < (gsi_top + NR_IRQS_LEGACY))
- gsi = irq - gsi_top;
- else
- gsi = 0x;
-
- return gsi;
-}
-
/*
* Temporarily use the virtual area starting from FIX_IO_APIC_BASE_END,
* to map the target physical address. The problem is that set_fixmap()
@@ -529,7 +517,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
{
if (isa_irq >= 16)
return -1;
- *gsi = irq_to_gsi(isa_irq);
+ *gsi = isa_irq_to_gsi[isa_irq];
return 0;
}
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index cb272c9..8d087f1 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1041,13 +1041,16 @@ static int pin_2_irq(int idx, int apic, int pin)
if (test_bit(bus, mp_bus_not_pci)) {
irq = mp_irqs[idx].srcbusirq;
- } else {
+ } else if (gsi_cfg->gsi_base == gsi_cfg->irq_base) {
u32 gsi = gsi_cfg->gsi_base + pin;
if (gsi >= NR_IRQS_LEGACY)
irq = gsi;
else
irq = gsi_top + gsi;
+ } else {
+ /* hotadd ioapic */
+ irq = gsi_cfg->irq_base + pin;
}
#ifdef CONFIG_X86_32
@@ -1473,6 +1476,30 @@ static void __init setup_IO_APIC_irqs(void)
__io_apic_setup_irqs(ioapic_idx);
}
+int ioapic_gsi_to_irq(u32 gsi)
+{
+ int ioapic_idx = 0, irq = gsi;
+ struct mp_ioapic_gsi *gsi_cfg;
+
+ ioapic_idx = mp_find_ioapic(gsi);
+ if (ioapic_idx < 0)
+ return -1;
+
+ gsi_cfg = mp_ioapic_gsi_routing(ioapic_idx);
+ if (gsi_cfg->gsi_base == gsi_cfg->irq_base) {
+ if (gsi < NR_IRQS_LEGACY)
+ irq = gsi_top + gsi;
+ } else {
+ int pin = mp_find_ioapic_pin(ioapic_idx, gsi);
+
+ if (pin < 0)
+ return -1;
+ /* hotadd ioapic */
+ irq = gsi_cfg->irq_base + pin;
+ }
+
+ return irq;
+}
/*
* for the gsit that is not in first ioapic
* but could not use acpi_register_gsi()
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 15/28] x86, irq: Split out alloc_ioapic_save_registers()
Split alloc_ioapic_save_registers() from early_irq_init(),
so it will be used per ioapic.
Will call that later for hot-added ioapic controller.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 18b123b..3e0530c 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -283,6 +283,19 @@ static struct irq_cfg
*alloc_reserved_irq_and_cfg_at(unsigned int at, int node)
/* irq_cfg is indexed by the sum of all RTEs in all I/O APICs. */
static struct irq_cfg irq_cfgx[NR_IRQS_LEGACY];
+static void alloc_ioapic_saved_registers(int idx)
+{
+ if (ioapics[idx].saved_registers)
+ return;
+
+ ioapics[idx].saved_registers =
+ kzalloc(sizeof(struct IO_APIC_route_entry) *
+ ioapics[idx].nr_registers, GFP_KERNEL);
+
+ if (!ioapics[idx].saved_registers)
+ pr_err("IOAPIC %d: suspend/resume impossible!\n", idx);
+}
+
int __init arch_early_irq_init(void)
{
struct irq_cfg *cfg;
@@ -291,13 +304,8 @@ int __init arch_early_irq_init(void)
if (!legacy_pic->nr_legacy_irqs)
io_apic_irqs = ~0UL;
- for (i = 0; i < nr_ioapics; i++) {
- ioapics[i].saved_registers =
- kzalloc(sizeof(struct IO_APIC_route_entry) *
- ioapics[i].nr_registers, GFP_KERNEL);
- if (!ioapics[i].saved_registers)
- pr_err("IOAPIC %d: suspend/resume impossible!\n", i);
- }
+ for (i = 0; i < nr_ioapics; i++)
+ alloc_ioapic_saved_registers(i);
cfg = irq_cfgx;
count = ARRAY_SIZE(irq_cfgx);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 23/28] x86, ioapic: Find usable ioapic id for 64bit.
Checking the id in register, if that is duplicated, will pick one and
update id register.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 38 +-
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a75e9d8..fb9bf06 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3652,19 +3652,22 @@ static int __init io_apic_get_unique_id(int ioapic, int
apic_id)
return apic_id;
}
-static u8 __init io_apic_unique_id(u8 id)
+static u8 __init io_apic_unique_id(int idx, u8 id)
{
if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
!APIC_XAPIC(apic_version[boot_cpu_physical_apicid]))
- return io_apic_get_unique_id(nr_ioapics, id);
+ return io_apic_get_unique_id(idx, id);
else
return id;
}
#else
-static u8 __init io_apic_unique_id(u8 id)
+static u8 io_apic_unique_id(int idx, u8 id)
{
int i;
+ u8 new_id;
+ unsigned long flags;
DECLARE_BITMAP(used, 256);
+ union IO_APIC_reg_00 reg_00;
bitmap_zero(used, 256);
for_each_ioapic(i)
@@ -3672,7 +3675,32 @@ static u8 __init io_apic_unique_id(u8 id)
if (!test_bit(id, used))
return id;
- return find_first_zero_bit(used, 256);
+
+ /* check register at first */
+ raw_spin_lock_irqsave(_lock, flags);
+ reg_00.raw = io_apic_read(idx, 0);
+ raw_spin_unlock_irqrestore(_lock, flags);
+ new_id = reg_00.bits.ID;
+ if (!test_bit(new_id, used)) {
+ apic_printk(APIC_VERBOSE, KERN_INFO
+ "IOAPIC[%d]: Using reg apic_id %d instead of %d\n",
+idx, new_id, id);
+ return new_id;
+ }
+
+ new_id = find_first_zero_bit(used, 256);
+ reg_00.bits.ID = new_id;
+ raw_spin_lock_irqsave(_lock, flags);
+ io_apic_write(idx, 0, reg_00.raw);
+ reg_00.raw = io_apic_read(idx, 0);
+ raw_spin_unlock_irqrestore(_lock, flags);
+
+ /* Sanity check */
+ if (reg_00.bits.ID != new_id)
+ pr_warn("IOAPIC[%d]: Unable to change apic_id to %d!\n",
+ idx, new_id);
+
+ return new_id;
}
#endif
@@ -3947,7 +3975,7 @@ int __mp_register_ioapic(int id, u32 address, u32
gsi_base, bool hotadd)
if (bad_ioapic_register(idx))
goto clear_out;
- ioapics[idx].mp_config.apicid = io_apic_unique_id(id);
+ ioapics[idx].mp_config.apicid = io_apic_unique_id(idx, id);
ioapics[idx].mp_config.apicver = io_apic_get_version(idx);
/*
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 25/28] PCI, x86: Make ioapic hotplug support built-in
ioapic hotplug should be built-in like pci root bus hotplug.
Also need to make it depends on X86_IO_APIC.
Signed-off-by: Yinghai Lu
---
drivers/pci/Kconfig | 3 ++-
drivers/pci/ioapic.c | 6 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 81944fb..6c9ede2 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -109,9 +109,10 @@ config PCI_PASID
If unsure, say N.
config PCI_IOAPIC
- tristate "PCI IO-APIC hotplug support" if X86
+ bool "PCI IO-APIC hotplug support" if X86
depends on PCI
depends on ACPI
+ depends on X86_IO_APIC
default !X86
config PCI_LABEL
diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
index 1b90579..7d6b157 100644
--- a/drivers/pci/ioapic.c
+++ b/drivers/pci/ioapic.c
@@ -113,6 +113,10 @@ static struct pci_driver ioapic_driver = {
.remove = ioapic_remove,
};
-module_pci_driver(ioapic_driver);
+static int __init ioapic_init(void)
+{
+ return pci_register_driver(_driver);
+}
+module_init(ioapic_init);
MODULE_LICENSE("GPL");
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 20/28] x86, irq: More strict checking about registering ioapic
1. check overlaping gsi range
for hot-add ioapic case, BIOS may have some entries in MADT
and also have setting in pci root bus with _GSB of DSDT.
2. check if entries is in right range.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index b026cc7..60c6706 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3818,12 +3818,9 @@ void __init ioapic_insert_resources(void)
}
}
-int mp_find_ioapic(u32 gsi)
+static int __mp_find_ioapic(u32 gsi)
{
- int i = 0;
-
- if (nr_ioapics == 0)
- return -1;
+ int i;
/* Find the IOAPIC that manages this GSI. */
for_each_ioapic(i) {
@@ -3833,10 +3830,19 @@ int mp_find_ioapic(u32 gsi)
return i;
}
- printk(KERN_ERR "ERROR: Unable to locate IOAPIC for GSI %d\n", gsi);
return -1;
}
+int mp_find_ioapic(u32 gsi)
+{
+ int ret = __mp_find_ioapic(gsi);
+
+ if (ret == -1)
+ pr_err("ERROR: Unable to locate IOAPIC for GSI %d\n", gsi);
+
+ return ret;
+}
+
int mp_find_ioapic_pin(int ioapic, u32 gsi)
{
struct mp_ioapic_gsi *gsi_cfg;
@@ -3888,6 +3894,11 @@ void __init mp_register_ioapic(int id, u32 address, u32
gsi_base)
if (bad_ioapic(address))
return;
+ /* already registered ? */
+ idx = __mp_find_ioapic(gsi_base);
+ if (idx >= 0)
+ return;
+
idx = find_first_zero_bit(ioapics_mask, MAX_IO_APICS);
if (idx >= MAX_IO_APICS) {
pr_warn("WARNING: Max # of I/O APICs (%d) exceeded, skipping\n",
@@ -3914,6 +3925,13 @@ void __init mp_register_ioapic(int id, u32 address, u32
gsi_base)
* and to prevent reprogramming of IOAPIC pins (PCI GSIs).
*/
entries = io_apic_get_redir_entries(idx);
+
+ if (!entries || entries > MP_MAX_IOAPIC_PIN) {
+ clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+ memset([idx], 0, sizeof(struct ioapic));
+ return;
+ }
+
gsi_cfg = mp_ioapic_gsi_routing(idx);
gsi_cfg->gsi_base = gsi_base;
gsi_cfg->gsi_end = gsi_base + entries - 1;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 13/28] x86, irq: Add alloc_reserved_irq_and_cfg_at()
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for new added ioapic controller.
We can reserve irq range at first, then allocate those
pre-reserved one when it is needed.
Add alloc_reserved_irq_and_cfg_at() to really allocate irq_desc and cfg,
because pre-reserved only mark bits in allocate_irqs bit maps.
Also fallback to alloc_irq_and_cfg_at(), and it is needed as
we do not actually reserved irq for io apic irq yet.
This patch is x86 arch code.
-v2: update changelog by adding reasons, requested by Konrad.
-v3: according to tglx, separate to another patch, and use
alloc_reserved_... instead of realloc_...
also add handling for one possible path in
alloc_reserved_irq_and_cfg_at().
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index ef2d530..c883da9 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -301,6 +301,29 @@ static void free_irq_at(unsigned int at, struct irq_cfg
*cfg)
irq_free_desc(at);
}
+static struct irq_cfg *alloc_reserved_irq_and_cfg_at(unsigned int at, int node)
+{
+ struct irq_cfg *cfg;
+ int res;
+
+ res = irq_alloc_reserved_desc_at(at, node);
+
+ if (res >= 0) {
+ cfg = irq_desc_get_chip_data(irq_to_desc(at));
+ if (cfg)
+ return cfg;
+
+ cfg = alloc_irq_cfg(at, node);
+ if (cfg)
+ irq_set_chip_data(at, cfg);
+ else
+ irq_free_desc(at);
+
+ return cfg;
+ }
+
+ return alloc_irq_and_cfg_at(at, node);
+}
struct io_apic {
unsigned int index;
@@ -3352,7 +3375,7 @@ int arch_setup_ht_irq(unsigned int irq, struct pci_dev
*dev)
static int
io_apic_setup_irq_pin(unsigned int irq, int node, struct io_apic_irq_attr
*attr)
{
- struct irq_cfg *cfg = alloc_irq_and_cfg_at(irq, node);
+ struct irq_cfg *cfg = alloc_reserved_irq_and_cfg_at(irq, node);
int ret;
if (!cfg)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 05/28] x86, irq: Modify irq chip once for irq remapping
Current code: after irq remapping is enabled, irq_chip fields are modified
during every irq setup.
mp_register_gsi
io_apic_set_pci_routing
io_apic_setup_irq_pin
setup_ioapic_irq
ioapic_register_intr
setup_remapped_irq
native_setup_msi_irqs
setup_msi_irq
setup_remapped_irq
default_setup_hpet_msi
setup_remapped_irq
that is not efficient.
We only need to modify those irq chip one time after we enable
irq remapping.
Change irq_remap_modify_chip_defaults() to __init as it only gets
called during booting stage, via irq_remap_modify_chips().
Affected irq_chip: ioapic_chip, msi_chip, hpet_msi_type.
We don't need to use #ifdef in irq_remap_modify_chips():
IRQ_REMAP only support x86_64 && X86_IO_APIC && PCI_MSI.
HPET_TIMER is selected when x86_64 is set.
When we have IRQ_REMAP enabled, al three chips are defined and
used.
-v3: Remove irq_chip in setup_remapped_irq according to Sebastian.
also add missing "\n" in printk.
Signed-off-by: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
Cc: Joerg Roedel
---
arch/x86/include/asm/io_apic.h | 5 +
arch/x86/include/asm/irq_remapping.h | 8 ++--
arch/x86/kernel/apic/apic.c | 9 -
arch/x86/kernel/apic/io_apic.c | 14 ++
drivers/iommu/irq_remapping.c| 13 ++---
5 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 459e50a..eaff3ad 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -215,6 +215,11 @@ static inline void io_apic_modify(unsigned int apic,
unsigned int reg, unsigned
extern void io_apic_eoi(unsigned int apic, unsigned int vector);
+extern struct irq_chip ioapic_chip;
+extern struct irq_chip msi_chip;
+extern struct irq_chip hpet_msi_type;
+void irq_remap_modify_chips(void);
+
#else /* !CONFIG_X86_IO_APIC */
#define io_apic_assign_pci_irqs 0
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 606f42e..304c93f 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -52,9 +52,7 @@ extern void compose_remapped_msi_msg(struct pci_dev *pdev,
struct msi_msg *msg, u8 hpet_id);
extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
extern void panic_if_irq_remap(const char *msg);
-extern bool setup_remapped_irq(int irq,
- struct irq_cfg *cfg,
- struct irq_chip *chip);
+extern bool setup_remapped_irq(int irq, struct irq_cfg *cfg);
#else /* CONFIG_IRQ_REMAP */
@@ -89,9 +87,7 @@ static inline void panic_if_irq_remap(const char *msg)
{
}
-static inline bool setup_remapped_irq(int irq,
- struct irq_cfg *cfg,
- struct irq_chip *chip)
+static inline bool setup_remapped_irq(int irq, struct irq_cfg *cfg)
{
return false;
}
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index eca89c5..9b64203 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1571,6 +1571,8 @@ void enable_x2apic(void)
int __init enable_IR(void)
{
#ifdef CONFIG_IRQ_REMAP
+ int ret;
+
if (!irq_remapping_supported()) {
pr_debug("intr-remapping not supported\n");
return -1;
@@ -1582,7 +1584,12 @@ int __init enable_IR(void)
return -1;
}
- return irq_remapping_enable();
+ ret = irq_remapping_enable();
+
+ if (ret >= 0)
+ irq_remap_modify_chips();
+
+ return ret;
#endif
return -1;
}
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..eda56ad 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1238,8 +1238,6 @@ void __setup_vector_irq(int cpu)
raw_spin_unlock(_lock);
}
-static struct irq_chip ioapic_chip;
-
#ifdef CONFIG_X86_32
static inline int IO_APIC_irq_trigger(int irq)
{
@@ -1280,7 +1278,7 @@ static void ioapic_register_intr(unsigned int irq, struct
irq_cfg *cfg,
fasteoi = false;
}
- if (setup_remapped_irq(irq, cfg, chip))
+ if (setup_remapped_irq(irq, cfg))
fasteoi = trigger != 0;
hdl = fasteoi ? handle_fasteoi_irq : handle_edge_irq;
@@ -2511,7 +2509,7 @@ static void ack_apic_level(struct irq_data *data)
ioapic_irqd_unmask(data, cfg, masked);
}
-static struct irq_chip ioapic_chip __read_mostly = {
+struct irq_chip ioapic_chip __read_mostly = {
.name = "IO-APIC",
.irq_startup= startup_ioapic_irq,
[PATCH v4 26/28] PCI, x86, ACPI: Link acpi ioapic register to ioapic
During ioapic hotplug, acpi_register_ioapic will be called.
Now for x86, that function is blank.
Fill that will update __mp_register_ioapic to use those ioapic.
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/acpi/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 5be15d1..4a5336d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -707,16 +707,18 @@ EXPORT_SYMBOL(acpi_unmap_lsapic);
int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base)
{
- /* TBD */
- return -EINVAL;
+ unsigned long long id = 0;
+
+ acpi_evaluate_integer(handle, "_UID", NULL, );
+
+ return __mp_register_ioapic(id, phys_addr, gsi_base, true);
}
EXPORT_SYMBOL(acpi_register_ioapic);
int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base)
{
- /* TBD */
- return -EINVAL;
+ return mp_unregister_ioapic(gsi_base);
}
EXPORT_SYMBOL(acpi_unregister_ioapic);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 21/28] x86, irq: Make mp_register_ioapic handle hot-added ioapic
It needs to reserve irq range in allocated_irqs bitmaps
and irq_base will be used to get right irq for ioapic/pin or gsi.
also need to use lock to protect ioapics_mask to avoid racing.
Signed-off-by: Yinghai Lu
Cc: Paul Gortmaker
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/mpspec.h | 1 +
arch/x86/kernel/apic/io_apic.c | 68 --
2 files changed, 54 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 626cf70..13cf60c 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -96,6 +96,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
void generic_processor_info(int apicid, int version);
#ifdef CONFIG_ACPI
+int __mp_register_ioapic(int id, u32 address, u32 gsi_base, bool hot);
extern void mp_register_ioapic(int id, u32 address, u32 gsi_base);
extern void mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
u32 gsi);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 60c6706..1616a35 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -94,6 +94,16 @@ static struct ioapic {
} ioapics[MAX_IO_APICS];
DECLARE_BITMAP(ioapics_mask, MAX_IO_APICS);
+static DEFINE_MUTEX(ioapics_mask_lock);
+
+static void lock_ioapics(void)
+{
+ mutex_lock(_mask_lock);
+}
+static void unlock_ioapics(void)
+{
+ mutex_unlock(_mask_lock);
+}
#define mpc_ioapic_ver(ioapic_idx) ioapics[ioapic_idx].mp_config.apicver
@@ -3885,25 +3895,28 @@ static __init int bad_ioapic_register(int idx)
return 0;
}
-void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
+int __mp_register_ioapic(int id, u32 address, u32 gsi_base, bool hotadd)
{
int idx;
int entries;
struct mp_ioapic_gsi *gsi_cfg;
+ int ret = -EINVAL;
if (bad_ioapic(address))
- return;
+ return ret;
+
+ lock_ioapics();
/* already registered ? */
idx = __mp_find_ioapic(gsi_base);
if (idx >= 0)
- return;
+ goto out;
idx = find_first_zero_bit(ioapics_mask, MAX_IO_APICS);
if (idx >= MAX_IO_APICS) {
pr_warn("WARNING: Max # of I/O APICs (%d) exceeded, skipping\n",
MAX_IO_APICS);
- return;
+ goto out;
}
ioapics[idx].mp_config.type = MP_IOAPIC;
@@ -3912,10 +3925,8 @@ void __init mp_register_ioapic(int id, u32 address, u32
gsi_base)
set_fixmap_nocache(FIX_IO_APIC_BASE_0 + idx, address);
- if (bad_ioapic_register(idx)) {
- clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
- return;
- }
+ if (bad_ioapic_register(idx))
+ goto clear_out;
ioapics[idx].mp_config.apicid = io_apic_unique_id(id);
ioapics[idx].mp_config.apicver = io_apic_get_version(idx);
@@ -3926,11 +3937,8 @@ void __init mp_register_ioapic(int id, u32 address, u32
gsi_base)
*/
entries = io_apic_get_redir_entries(idx);
- if (!entries || entries > MP_MAX_IOAPIC_PIN) {
- clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
- memset([idx], 0, sizeof(struct ioapic));
- return;
- }
+ if (!entries || entries > MP_MAX_IOAPIC_PIN)
+ goto clear_out;
gsi_cfg = mp_ioapic_gsi_routing(idx);
gsi_cfg->gsi_base = gsi_base;
@@ -3941,8 +3949,21 @@ void __init mp_register_ioapic(int id, u32 address, u32
gsi_base)
*/
ioapics[idx].nr_registers = entries;
- if (gsi_cfg->gsi_end >= gsi_top)
- gsi_top = gsi_cfg->gsi_end + 1;
+ if (!hotadd) {
+ /*
+* irqs will be reserved in arch_early_irq_init()
+* don't need to update gsi_top for hot add case
+*/
+ if (gsi_cfg->gsi_end >= gsi_top)
+ gsi_top = gsi_cfg->gsi_end + 1;
+ } else {
+ int irq = reserve_ioapic_gsi_irq_base(idx);
+
+ if (irq < 0)
+ goto clear_out;
+
+ alloc_ioapic_saved_registers(idx);
+ }
pr_info("IOAPIC[%d]: apic_id %d, version %d, address 0x%x, GSI %d-%d\n",
idx, mpc_ioapic_id(idx),
@@ -3951,6 +3972,23 @@ void __init mp_register_ioapic(int id, u32 address, u32
gsi_base)
set_bit(idx, ioapics_mask);
nr_ioapics = bitmap_weight(ioapics_mask, MAX_IO_APICS);
+
+ unlock_ioapics();
+
+ return 0;
+
+clear_out:
+ clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+ memset([idx], 0, sizeof(struct ioapic));
+out:
+ unlock_ioapics();
+
+ return ret;
+}
+
+void mp_register_ioapic(int id, u32 address, u32 gsi_base)
+{
+ __mp_register_ioapic(id, address, gsi_base, false);
}
[PATCH v4 16/28] xen, irq: Call irq_alloc_reserved_desc_at() at first
To make x86 irq allocation to be same with booting path and ioapic
hot add path, We will pre-reserve irq for all gsi at first.
We have to use alloc_reserved here, otherwise irq_alloc_desc_at will fail
because bit is already get marked for pre-reserved in irq bitmaps.
Signed-off-by: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc: xen-de...@lists.xensource.com
---
drivers/xen/events.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index a58ac43..1a3647c 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -507,8 +507,12 @@ static int __must_check xen_allocate_irq_gsi(unsigned gsi)
/* Legacy IRQ descriptors are already allocated by the arch. */
if (gsi < NR_IRQS_LEGACY)
irq = gsi;
- else
- irq = irq_alloc_desc_at(gsi, -1);
+ else {
+ /* for x86, irq already get reserved for gsi */
+ irq = irq_alloc_reserved_desc_at(gsi, -1);
+ if (irq < 0)
+ irq = irq_alloc_desc_at(gsi, -1);
+ }
xen_irq_init(irq);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 03/28] genirq: Do not free unallocated irq descriptors
Hot-added interrupt controllers can reserve a range of interrupt
numbers, but only allocate some of them. To simplify the release on
hot-remove allow them to iterate over the reserved range, let the
free_desc() code return early when the descriptor does not exist
-v2: changelog from tglx
Signed-off-by: Yinghai Lu
---
kernel/irq/irqdesc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 1166545..bbf0601 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -165,6 +165,9 @@ static void free_desc(unsigned int irq)
{
struct irq_desc *desc = irq_to_desc(irq);
+ if (!desc)
+ return;
+
unregister_irq_proc(irq, desc);
mutex_lock(_irq_lock);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 22/28] x86, irq: Add mp_unregister_ioapic to handle hot-remove ioapic
It will free ioapic related irq_desc and also clear allocated_irqs bits.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/mpspec.h | 1 +
arch/x86/kernel/apic/io_apic.c | 44 ++
2 files changed, 45 insertions(+)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 13cf60c..49f6ecc 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -97,6 +97,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
void generic_processor_info(int apicid, int version);
#ifdef CONFIG_ACPI
int __mp_register_ioapic(int id, u32 address, u32 gsi_base, bool hot);
+int mp_unregister_ioapic(u32 gsi_base);
extern void mp_register_ioapic(int id, u32 address, u32 gsi_base);
extern void mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
u32 gsi);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1616a35..a75e9d8 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -334,6 +334,20 @@ static void __init reserve_ioapic_gsi_irq_extra(void)
}
}
+static void free_ioapic_gsi_irq_base(int idx)
+{
+ int i;
+ struct mp_ioapic_gsi *gsi_cfg = mp_ioapic_gsi_routing(idx);
+ int irq_base = gsi_cfg->irq_base;
+ int irq_cnt = gsi_cfg->gsi_end - gsi_cfg->gsi_base + 1;
+
+ if (irq_base < 0)
+ return;
+
+ for (i = irq_base; i < irq_base + irq_cnt; i++)
+ free_irq_at(i, irq_get_chip_data(i));
+}
+
static void alloc_ioapic_saved_registers(int idx)
{
if (ioapics[idx].saved_registers)
@@ -347,6 +361,11 @@ static void alloc_ioapic_saved_registers(int idx)
pr_err("IOAPIC %d: suspend/resume impossible!\n", idx);
}
+static void free_ioapic_saved_registers(int idx)
+{
+ kfree(ioapics[idx].saved_registers);
+}
+
int __init arch_early_irq_init(void)
{
int node = cpu_to_node(0);
@@ -3991,6 +4010,31 @@ void mp_register_ioapic(int id, u32 address, u32
gsi_base)
__mp_register_ioapic(id, address, gsi_base, false);
}
+int mp_unregister_ioapic(u32 gsi_base)
+{
+ int idx;
+
+ lock_ioapics();
+
+ idx = __mp_find_ioapic(gsi_base);
+ if (idx < 0) {
+ unlock_ioapics();
+ return -EINVAL;
+ }
+
+ free_ioapic_saved_registers(idx);
+
+ free_ioapic_gsi_irq_base(idx);
+
+ clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+ memset([idx], 0, sizeof(struct ioapic));
+ clear_bit(idx, ioapics_mask);
+
+ unlock_ioapics();
+
+ return 0;
+}
+
/* Enable IOAPIC early just for system timer */
void __init pre_init_apic_IRQ0(void)
{
--
1.8.1.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 00/28] x86, irq: Support ioapic controller hotplug
Hi, Intel cpu (from IVB) include cpu cores, mem controller, and IIO. When hotplug cpu physically, it will involve cpu hotplug, mem hotplug, and pci root hotplug. IIO includes pci host bridge, ioapic controller and iommu etc. pci devices will need to use ioapic and iommu. So to make pci root bus hotplug working, we need ioapic hotplug support. Now ioapics are with ACPI MADT table. During booting, kernel will parse MADT and put info into ioapic arrays. Also Bjorn added one pci device based driver, but it is not wired in yet, as it need to call acpi_register_ioapic, and that is TBD. This patchset will 1. extend genirq to support reserve/alloc_reserved method. because we want irqs for one ioapic controller to be linear mapping to the gsi range. 2. change ioapic array operation code so we could insert new ioapic and remove one leave the blank slot. 3. record irq_base in gsi_config in ioapic struct, and use it to convert gsi to irq for pci device using that ioapic controller 4. make static ioapic path (from MADT) use same code as hot-add path, with reserve/alloc_reserved method. 5. change ioapic add/remove to use acpi way, as that is only needed when pci root bus hotplug. 6. also support the case that ioapic controller is hiding in pci config space or ioapic address is not managed by pci reallocation subsys. Also include some cleanups 1. print MSI-X clearly in /proc/interrupts and dmesg. 2. convert ioapic irq_2_pin to be generic list. It is based on linus's tree of 2013/08/10 aka v3.11-rc4. could get them from: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-irq -v3: split last patch to 4 patches per request from Bjorn. drop one patch that will put pci device name in proc/interrupts update changelog. -v4: address review from tglx, change to realloc to alloc_reserved. separate x86 code and core code into different patches. Yinghai Lu (28): genirq: Split __irq_reserve_irqs from irq_alloc_descs genirq: Add irq_alloc_reserved_desc() genirq: Do not free unallocated irq descriptors x86, irq: Change irq_remap_modify_chip_defaults() to static x86, irq: Modify irq chip once for irq remapping x86, irq: Show MSI-X clearly in debug message x86, irq: Show MSI-X in /proc/interrupt x86, irq: Make dmar_msi/hpet_msi irq_chip name consistent ia64, irq: Add dummy create_irq_nr() iommu, irq: Allocate irq_desc for dmar_msi with local node x86, irq: Kill create_irq() x86, irq: Convert irq_2_pin list to generic list x86, irq: Add alloc_reserved_irq_and_cfg_at() x86, irq: Move down arch_early_irq_init() x86, irq: Split out alloc_ioapic_save_registers() xen, irq: Call irq_alloc_reserved_desc_at() at first x86, irq: Reserve irq range and alloc_reserved for booting path x86, irq: Add ioapic_gsi_to_irq x86, irq: Add for_each_ioapic helper x86, irq: More strict checking about registering ioapic x86, irq: Make mp_register_ioapic handle hot-added ioapic x86, irq: Add mp_unregister_ioapic to handle hot-remove ioapic x86, ioapic: Find usable ioapic id for 64bit. x86: Move declaration for mp_register_ioapic() PCI, x86: Make ioapic hotplug support built-in PCI, x86, ACPI: Link acpi ioapic register to ioapic PCI, x86, ACPI: Enable ioapic hotplug support with acpi host bridge. PCI, x86, ACPI: get ioapic address from acpi device arch/ia64/kernel/irq_ia64.c | 10 + arch/x86/include/asm/hw_irq.h| 2 +- arch/x86/include/asm/io_apic.h | 13 + arch/x86/include/asm/irq_remapping.h | 14 +- arch/x86/include/asm/mpspec.h| 21 +- arch/x86/kernel/acpi/boot.c | 32 +-- arch/x86/kernel/apic/apic.c | 9 +- arch/x86/kernel/apic/io_apic.c | 480 +-- arch/x86/kernel/devicetree.c | 2 +- drivers/acpi/pci_root.c | 4 + drivers/iommu/amd_iommu_init.c | 2 +- drivers/iommu/dmar.c | 2 +- drivers/iommu/intel_irq_remapping.c | 2 +- drivers/iommu/irq_remapping.c| 18 +- drivers/pci/Kconfig | 3 +- drivers/pci/ioapic.c | 229 - drivers/xen/events.c | 8 +- include/linux/irq.h | 4 + include/linux/pci-acpi.h | 8 + kernel/irq/irqdesc.c | 80 -- 20 files changed, 679 insertions(+), 264 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 17/28] x86, irq: Reserve irq range and alloc_reserved for booting path
We will use reserve and alloc_reserved_irq_and_cfg_at for hotplug ioapic path.
To make thing simple, we could make booting path use same code.
All irq range for all GSIs will be reserved at first, and alloc_reserved
will really allocate those irq_desc/cfg when it is used.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/io_apic.h | 1 +
arch/x86/kernel/apic/io_apic.c | 80 +++---
2 files changed, 60 insertions(+), 21 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index eaff3ad..8181fd8 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -176,6 +176,7 @@ extern void setup_ioapic_ids_from_mpc_nocheck(void);
struct mp_ioapic_gsi{
u32 gsi_base;
u32 gsi_end;
+ u32 irq_base;
};
extern struct mp_ioapic_gsi mp_gsi_routing[];
extern u32 gsi_top;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 3e0530c..cb272c9 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -280,8 +280,47 @@ static struct irq_cfg
*alloc_reserved_irq_and_cfg_at(unsigned int at, int node)
return alloc_irq_and_cfg_at(at, node);
}
-/* irq_cfg is indexed by the sum of all RTEs in all I/O APICs. */
-static struct irq_cfg irq_cfgx[NR_IRQS_LEGACY];
+static int reserve_ioapic_gsi_irq_base(int idx)
+{
+ int irq;
+ struct mp_ioapic_gsi *gsi_cfg = mp_ioapic_gsi_routing(idx);
+ int cnt = gsi_cfg->gsi_end - gsi_cfg->gsi_base + 1;
+
+ irq = __irq_reserve_irqs(-1, gsi_cfg->gsi_base, cnt);
+ if (irq >= 0) {
+ gsi_cfg->irq_base = irq;
+ apic_printk(APIC_VERBOSE, KERN_INFO
+ "IOAPIC[%d]: apic_id %d, GSI %d-%d ==> irq %d-%d
reserved\n",
+ idx, mpc_ioapic_id(idx),
+ gsi_cfg->gsi_base, gsi_cfg->gsi_end,
+ irq, irq + cnt - 1);
+ } else
+ apic_printk(APIC_VERBOSE, KERN_WARNING
+ "IOAPIC[%d]: apic_id %d, GSI %d-%d ==> irq reserve
failed\n",
+ idx, mpc_ioapic_id(idx),
+ gsi_cfg->gsi_base, gsi_cfg->gsi_end);
+
+ return irq;
+}
+
+static void __init reserve_ioapic_gsi_irq_extra(void)
+{
+ int irq;
+
+ /* to prevent hot add ioapic taking those slots */
+ if (gsi_top) {
+ irq = irq_reserve_irqs(gsi_top, NR_IRQS_LEGACY);
+ if (irq >= 0)
+ apic_printk(APIC_VERBOSE, KERN_INFO
+ "IOAPIC[extra]: GSI %d-%d ==> irq %d-%d
reserved\n",
+ gsi_top, gsi_top + NR_IRQS_LEGACY - 1,
+ irq, irq + NR_IRQS_LEGACY - 1);
+ else
+ apic_printk(APIC_VERBOSE, KERN_WARNING
+ "IOAPIC[extra]: GSI %d-%d ==> irq reserve
failed\n",
+ gsi_top, gsi_top + NR_IRQS_LEGACY - 1);
+ }
+}
static void alloc_ioapic_saved_registers(int idx)
{
@@ -298,8 +337,9 @@ static void alloc_ioapic_saved_registers(int idx)
int __init arch_early_irq_init(void)
{
+ int node = cpu_to_node(0);
struct irq_cfg *cfg;
- int count, node, i;
+ int i;
if (!legacy_pic->nr_legacy_irqs)
io_apic_irqs = ~0UL;
@@ -307,26 +347,23 @@ int __init arch_early_irq_init(void)
for (i = 0; i < nr_ioapics; i++)
alloc_ioapic_saved_registers(i);
- cfg = irq_cfgx;
- count = ARRAY_SIZE(irq_cfgx);
- node = cpu_to_node(0);
+ for (i = 0; i < nr_ioapics; i++)
+ reserve_ioapic_gsi_irq_base(i);
- /* Make sure the legacy interrupts are marked in the bitmap */
- irq_reserve_irqs(0, legacy_pic->nr_legacy_irqs);
+ reserve_ioapic_gsi_irq_extra();
- for (i = 0; i < count; i++) {
- INIT_LIST_HEAD([i].irq_2_pin);
- irq_set_chip_data(i, [i]);
- zalloc_cpumask_var_node([i].domain, GFP_KERNEL, node);
- zalloc_cpumask_var_node([i].old_domain, GFP_KERNEL, node);
- /*
-* For legacy IRQ's, start with assigning irq0 to irq15 to
-* IRQ0_VECTOR to IRQ15_VECTOR for all cpu's.
-*/
- if (i < legacy_pic->nr_legacy_irqs) {
- cfg[i].vector = IRQ0_VECTOR + i;
- cpumask_setall(cfg[i].domain);
+ /*
+* For legacy IRQ's, start with assigning irq0 to irq15 to
+* IRQ0_VECTOR to IRQ15_VECTOR for all cpu's.
+*/
+ for (i = 0; i < legacy_pic->nr_legacy_irqs; i++) {
+ cfg = alloc_reserved_irq_and_cfg_at(i, node);
+ if (!cfg) {
+ pr_warn("can not allocate irq_desc/cfg for %d\n", i);
+
[PATCH 03/28] genirq: Do not free unallocated irq descriptors
Hot-added interrupt controllers can reserve a range of interrupt
numbers, but only allocate some of them. To simplify the release on
hot-remove allow them to iterate over the reserved range, let the
free_desc() code return early when the descriptor does not exist
-v2: changelog from tglx
Signed-off-by: Yinghai Lu
---
kernel/irq/irqdesc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 1166545..bbf0601 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -165,6 +165,9 @@ static void free_desc(unsigned int irq)
{
struct irq_desc *desc = irq_to_desc(irq);
+ if (!desc)
+ return;
+
unregister_irq_proc(irq, desc);
mutex_lock(_irq_lock);
--
1.8.1.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 10/28] iommu, irq: Allocate irq_desc for dmar_msi with local node
iommu irq's irq_desc should be on local node ram.
Fix the return value checking problem.
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
here only check !irq, so need to change it to use create_irq_nr instead.
-v2: According to Sebastian, add cc to stable.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Donald Dutile
Acked-by: Donald Dutile
Cc: Sebastian Andrzej Siewior
Cc: sta...@vger.kernel.org
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 785675a..db41e36 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1277,7 +1277,7 @@ int dmar_set_interrupt(struct intel_iommu *iommu)
if (iommu->irq)
return 0;
- irq = create_irq();
+ irq = create_irq_nr(0, iommu->node);
if (!irq) {
pr_err("IOMMU: no free vectors\n");
return -EINVAL;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 24/28] x86: Move declaration for mp_register_ioapic()
Address compiling problem that Fengguang report.
Reported-by: Fengguang Wu
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/mpspec.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 49f6ecc..a57f113 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -95,10 +95,27 @@ static inline void early_reserve_e820_mpc_new(void) { }
#endif
void generic_processor_info(int apicid, int version);
-#ifdef CONFIG_ACPI
+
+#ifdef CONFIG_X86_IO_APIC
int __mp_register_ioapic(int id, u32 address, u32 gsi_base, bool hot);
int mp_unregister_ioapic(u32 gsi_base);
extern void mp_register_ioapic(int id, u32 address, u32 gsi_base);
+#else
+static inline int __mp_register_ioapic(int id, u32 address, u32 gsi_base,
+bool hot)
+{
+ return 0;
+}
+static inline int mp_unregister_ioapic(u32 gsi_base)
+{
+ return 0;
+}
+static inline void mp_register_ioapic(int id, u32 address, u32 gsi_base)
+{
+}
+#endif
+
+#ifdef CONFIG_ACPI
extern void mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
u32 gsi);
extern void mp_config_acpi_legacy_irqs(void);
--
1.8.1.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 05/28] x86, irq: Modify irq chip once for irq remapping
Current code: after irq remapping is enabled, irq_chip fields are modified
during every irq setup.
mp_register_gsi
io_apic_set_pci_routing
io_apic_setup_irq_pin
setup_ioapic_irq
ioapic_register_intr
setup_remapped_irq
native_setup_msi_irqs
setup_msi_irq
setup_remapped_irq
default_setup_hpet_msi
setup_remapped_irq
that is not efficient.
We only need to modify those irq chip one time after we enable
irq remapping.
Change irq_remap_modify_chip_defaults() to __init as it only gets
called during booting stage, via irq_remap_modify_chips().
Affected irq_chip: ioapic_chip, msi_chip, hpet_msi_type.
We don't need to use #ifdef in irq_remap_modify_chips():
IRQ_REMAP only support x86_64 && X86_IO_APIC && PCI_MSI.
HPET_TIMER is selected when x86_64 is set.
When we have IRQ_REMAP enabled, al three chips are defined and
used.
-v3: Remove irq_chip in setup_remapped_irq according to Sebastian.
also add missing "\n" in printk.
Signed-off-by: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
Cc: Joerg Roedel
---
arch/x86/include/asm/io_apic.h | 5 +
arch/x86/include/asm/irq_remapping.h | 8 ++--
arch/x86/kernel/apic/apic.c | 9 -
arch/x86/kernel/apic/io_apic.c | 14 ++
drivers/iommu/irq_remapping.c| 13 ++---
5 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 459e50a..eaff3ad 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -215,6 +215,11 @@ static inline void io_apic_modify(unsigned int apic,
unsigned int reg, unsigned
extern void io_apic_eoi(unsigned int apic, unsigned int vector);
+extern struct irq_chip ioapic_chip;
+extern struct irq_chip msi_chip;
+extern struct irq_chip hpet_msi_type;
+void irq_remap_modify_chips(void);
+
#else /* !CONFIG_X86_IO_APIC */
#define io_apic_assign_pci_irqs 0
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 606f42e..304c93f 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -52,9 +52,7 @@ extern void compose_remapped_msi_msg(struct pci_dev *pdev,
struct msi_msg *msg, u8 hpet_id);
extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
extern void panic_if_irq_remap(const char *msg);
-extern bool setup_remapped_irq(int irq,
- struct irq_cfg *cfg,
- struct irq_chip *chip);
+extern bool setup_remapped_irq(int irq, struct irq_cfg *cfg);
#else /* CONFIG_IRQ_REMAP */
@@ -89,9 +87,7 @@ static inline void panic_if_irq_remap(const char *msg)
{
}
-static inline bool setup_remapped_irq(int irq,
- struct irq_cfg *cfg,
- struct irq_chip *chip)
+static inline bool setup_remapped_irq(int irq, struct irq_cfg *cfg)
{
return false;
}
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index eca89c5..9b64203 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1571,6 +1571,8 @@ void enable_x2apic(void)
int __init enable_IR(void)
{
#ifdef CONFIG_IRQ_REMAP
+ int ret;
+
if (!irq_remapping_supported()) {
pr_debug("intr-remapping not supported\n");
return -1;
@@ -1582,7 +1584,12 @@ int __init enable_IR(void)
return -1;
}
- return irq_remapping_enable();
+ ret = irq_remapping_enable();
+
+ if (ret >= 0)
+ irq_remap_modify_chips();
+
+ return ret;
#endif
return -1;
}
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..eda56ad 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1238,8 +1238,6 @@ void __setup_vector_irq(int cpu)
raw_spin_unlock(_lock);
}
-static struct irq_chip ioapic_chip;
-
#ifdef CONFIG_X86_32
static inline int IO_APIC_irq_trigger(int irq)
{
@@ -1280,7 +1278,7 @@ static void ioapic_register_intr(unsigned int irq, struct
irq_cfg *cfg,
fasteoi = false;
}
- if (setup_remapped_irq(irq, cfg, chip))
+ if (setup_remapped_irq(irq, cfg))
fasteoi = trigger != 0;
hdl = fasteoi ? handle_fasteoi_irq : handle_edge_irq;
@@ -2511,7 +2509,7 @@ static void ack_apic_level(struct irq_data *data)
ioapic_irqd_unmask(data, cfg, masked);
}
-static struct irq_chip ioapic_chip __read_mostly = {
+struct irq_chip ioapic_chip __read_mostly = {
.name = "IO-APIC",
.irq_startup= startup_ioapic_irq,
[PATCH v4 28/28] PCI, x86, ACPI: get ioapic address from acpi device
Some ioapic controllers do not show up on pci config space,
or pci device is there but no bar is used and is set by firmware in
other non standard registers.
We can get ioapic address from ACPI0009's _CRS.
Signed-off-by: Yinghai Lu
---
drivers/pci/ioapic.c | 86 +++-
1 file changed, 71 insertions(+), 15 deletions(-)
diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
index 60351b2..41f7c69 100644
--- a/drivers/pci/ioapic.c
+++ b/drivers/pci/ioapic.c
@@ -32,6 +32,36 @@ struct acpi_pci_ioapic {
static LIST_HEAD(ioapic_list);
static DEFINE_MUTEX(ioapic_list_lock);
+static acpi_status setup_res(struct acpi_resource *acpi_res, void *data)
+{
+ struct resource *res;
+ struct acpi_resource_address64 addr;
+ acpi_status status;
+ unsigned long flags;
+ u64 start, end;
+
+ status = acpi_resource_to_address64(acpi_res, );
+ if (!ACPI_SUCCESS(status))
+ return AE_OK;
+
+ if (addr.resource_type == ACPI_MEMORY_RANGE) {
+ if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
+ return AE_OK;
+ flags = IORESOURCE_MEM;
+ } else
+ return AE_OK;
+
+ start = addr.minimum + addr.translation_offset;
+ end = addr.maximum + addr.translation_offset;
+
+ res = data;
+ res->flags = flags;
+ res->start = start;
+ res->end = end;
+
+ return AE_OK;
+}
+
static void handle_ioapic_add(acpi_handle handle, struct pci_dev **pdev,
u32 *pgsi_base)
{
@@ -54,33 +84,56 @@ static void handle_ioapic_add(acpi_handle handle, struct
pci_dev **pdev,
return;
dev = acpi_get_pci_dev(handle);
- if (!dev)
- return;
+ if (!dev || !pci_resource_len(dev, 0)) {
+ struct acpi_device_info *info;
+ char *hid = NULL;
+
+ status = acpi_get_object_info(handle, );
+ if (ACPI_FAILURE(status))
+ goto exit_put;
+ if (info->valid & ACPI_VALID_HID)
+ hid = info->hardware_id.string;
+ if (!hid || strcmp(hid, "ACPI0009")) {
+ kfree(info);
+ goto exit_put;
+ }
+ kfree(info);
+ memset(res, 0, sizeof(*res));
+ acpi_walk_resources(handle, METHOD_NAME__CRS, setup_res, res);
+ if (!res->flags)
+ goto exit_put;
+ }
acpi_get_name(handle, ACPI_FULL_PATHNAME, );
gsi_base = gsb;
type = "IOxAPIC";
+ if (dev) {
+ ret = pci_enable_device(dev);
+ if (ret < 0)
+ goto exit_put;
- ret = pci_enable_device(dev);
- if (ret < 0)
- goto exit_put;
-
- pci_set_master(dev);
+ pci_set_master(dev);
- if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
- type = "IOAPIC";
+ if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
+ type = "IOAPIC";
- if (pci_request_region(dev, 0, type))
- goto exit_disable;
+ if (pci_resource_len(dev, 0)) {
+ if (pci_request_region(dev, 0, type))
+ goto exit_disable;
- res = >resource[0];
+ res = >resource[0];
+ }
+ }
- if (acpi_register_ioapic(handle, res->start, gsi_base))
- goto exit_release;
+ if (acpi_register_ioapic(handle, res->start, gsi_base)) {
+ if (dev)
+ goto exit_release;
+ return;
+ }
pr_info("%s %s %s at %pR, GSI %u\n",
- dev_name(>dev), objname, type,
+ dev ? dev_name(>dev) : "", objname, type,
res, gsi_base);
*pdev = dev;
@@ -100,6 +153,9 @@ static void handle_ioapic_remove(acpi_handle handle, struct
pci_dev *dev,
{
acpi_unregister_ioapic(handle, gsi_base);
+ if (!dev)
+ return;
+
pci_release_region(dev, 0);
pci_disable_device(dev);
pci_dev_put(dev);
--
1.8.1.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 08/28] x86, irq: Make dmar_msi/hpet_msi irq_chip name consistent
All others are using "-" instead of "_".
Change dmar_msi and hpet_msi to use "-".
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index cf320fb..47add1a 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3199,7 +3199,7 @@ dmar_msi_set_affinity(struct irq_data *data, const struct
cpumask *mask,
}
static struct irq_chip dmar_msi_type = {
- .name = "DMAR_MSI",
+ .name = "DMAR-MSI",
.irq_unmask = dmar_msi_unmask,
.irq_mask = dmar_msi_mask,
.irq_ack= ack_apic_edge,
@@ -3247,7 +3247,7 @@ static int hpet_msi_set_affinity(struct irq_data *data,
}
struct irq_chip hpet_msi_type = {
- .name = "HPET_MSI",
+ .name = "HPET-MSI",
.irq_unmask = hpet_msi_unmask,
.irq_mask = hpet_msi_mask,
.irq_ack = ack_apic_edge,
--
1.8.1.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 01/28] genirq: Split __irq_reserve_irqs from irq_alloc_descs
irq_alloc_descs and irq_reserve_irqs are almost the same.
Separate code out to __irq_reserved_irqs, and other two reuse
__irq_reserve_irqs.
We will use __irq_reserve_irqs for coming ioapic hotplug support.
-v2: fix func docbook related comments, pointed out by tglx.
Signed-off-by: Yinghai Lu
Cc: Alexander Gordeev
Reviewed-by: Alexander Gordeev
---
include/linux/irq.h | 1 +
kernel/irq/irqdesc.c | 54 ++--
2 files changed, 32 insertions(+), 23 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index f04d3ba..8c46cb2 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -611,6 +611,7 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned
int cnt, int node,
void irq_free_descs(unsigned int irq, unsigned int cnt);
int irq_reserve_irqs(unsigned int from, unsigned int cnt);
+int __irq_reserve_irqs(int irq, unsigned int from, unsigned int cnt);
static inline void irq_free_desc(unsigned int irq)
{
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 192a302..a151db6 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -340,18 +340,15 @@ void irq_free_descs(unsigned int from, unsigned int cnt)
EXPORT_SYMBOL_GPL(irq_free_descs);
/**
- * irq_alloc_descs - allocate and initialize a range of irq descriptors
- * @irq: Allocate for specific irq number if irq >= 0
+ * __irq_reserve_irqs - reserve a range of irqs
+ * @irq: Reserve for specific irq number if irq >= 0
* @from: Start the search from this irq number
- * @cnt: Number of consecutive irqs to allocate.
- * @node: Preferred node on which the irq descriptor should be allocated
- * @owner: Owning module (can be NULL)
+ * @cnt: Number of consecutive irqs to reserve.
*
* Returns the first irq number or error code
*/
int __ref
-__irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
- struct module *owner)
+__irq_reserve_irqs(int irq, unsigned int from, unsigned int cnt)
{
int start, ret;
@@ -369,7 +366,7 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned int
cnt, int node,
start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,
from, cnt, 0);
ret = -EEXIST;
- if (irq >=0 && start != irq)
+ if (irq >= 0 && start != irq)
goto err;
if (start + cnt > nr_irqs) {
@@ -380,12 +377,36 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned
int cnt, int node,
bitmap_set(allocated_irqs, start, cnt);
mutex_unlock(_irq_lock);
- return alloc_descs(start, cnt, node, owner);
+ return start;
err:
mutex_unlock(_irq_lock);
return ret;
}
+
+/**
+ * __irq_alloc_descs - allocate and initialize a range of irq descriptors
+ * @irq: Allocate for specific irq number if irq >= 0
+ * @from: Start the search from this irq number
+ * @cnt: Number of consecutive irqs to allocate.
+ * @node: Preferred node on which the irq descriptor should be allocated
+ * @owner: Owning module (can be NULL)
+ *
+ * Returns the first irq number or error code
+ */
+int __ref
+__irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
+ struct module *owner)
+{
+ int start;
+
+ start = __irq_reserve_irqs(irq, from, cnt);
+
+ if (start < 0)
+ return start;
+
+ return alloc_descs(start, cnt, node, owner);
+}
EXPORT_SYMBOL_GPL(__irq_alloc_descs);
/**
@@ -397,20 +418,7 @@ EXPORT_SYMBOL_GPL(__irq_alloc_descs);
*/
int irq_reserve_irqs(unsigned int from, unsigned int cnt)
{
- unsigned int start;
- int ret = 0;
-
- if (!cnt || (from + cnt) > nr_irqs)
- return -EINVAL;
-
- mutex_lock(_irq_lock);
- start = bitmap_find_next_zero_area(allocated_irqs, nr_irqs, from, cnt,
0);
- if (start == from)
- bitmap_set(allocated_irqs, start, cnt);
- else
- ret = -EEXIST;
- mutex_unlock(_irq_lock);
- return ret;
+ return __irq_reserve_irqs(from, from, cnt);
}
/**
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 12/28] x86, irq: Convert irq_2_pin list to generic list
Now irq_2_pin list is own grown list for ioapic irq/pin tracking.
We can use generic list to replace it so we could use generic helper
functions to operate it.
Also make free_irq_cfg() free irq_2_pin list to support coming ioapic
hotplug.
Signed-off-by: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
Cc: Joerg Roedel
---
arch/x86/include/asm/hw_irq.h | 2 +-
arch/x86/kernel/apic/io_apic.c | 22 --
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index e4ac559..8504333 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -139,7 +139,7 @@ struct irq_2_irte {
* Most irqs are mapped 1:1 with pins.
*/
struct irq_cfg {
- struct irq_pin_list *irq_2_pin;
+ struct list_headirq_2_pin;
cpumask_var_t domain;
cpumask_var_t old_domain;
u8 vector;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index ccfb1d3..ef2d530 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -66,7 +66,7 @@
#define __apicdebuginit(type) static type __init
#define for_each_irq_pin(entry, head) \
- for (entry = head; entry; entry = entry->next)
+ list_for_each_entry(entry, , list)
/*
* Is the SiS APIC rmw bug present ?
@@ -176,8 +176,8 @@ void mp_save_irq(struct mpc_intsrc *m)
}
struct irq_pin_list {
+ struct list_head list;
int apic, pin;
- struct irq_pin_list *next;
};
static struct irq_pin_list *alloc_irq_pin_list(int node)
@@ -213,6 +213,7 @@ int __init arch_early_irq_init(void)
irq_reserve_irqs(0, legacy_pic->nr_legacy_irqs);
for (i = 0; i < count; i++) {
+ INIT_LIST_HEAD([i].irq_2_pin);
irq_set_chip_data(i, [i]);
zalloc_cpumask_var_node([i].domain, GFP_KERNEL, node);
zalloc_cpumask_var_node([i].old_domain, GFP_KERNEL, node);
@@ -245,6 +246,7 @@ static struct irq_cfg *alloc_irq_cfg(unsigned int irq, int
node)
goto out_cfg;
if (!zalloc_cpumask_var_node(>old_domain, GFP_KERNEL, node))
goto out_domain;
+ INIT_LIST_HEAD(>irq_2_pin);
return cfg;
out_domain:
free_cpumask_var(cfg->domain);
@@ -255,11 +257,15 @@ out_cfg:
static void free_irq_cfg(unsigned int at, struct irq_cfg *cfg)
{
+ struct irq_pin_list *entry, *tmp;
+
if (!cfg)
return;
irq_set_chip_data(at, NULL);
free_cpumask_var(cfg->domain);
free_cpumask_var(cfg->old_domain);
+ list_for_each_entry_safe(entry, tmp, >irq_2_pin, list)
+ kfree(entry);
kfree(cfg);
}
@@ -420,15 +426,12 @@ static void ioapic_mask_entry(int apic, int pin)
*/
static int __add_pin_to_irq_node(struct irq_cfg *cfg, int node, int apic, int
pin)
{
- struct irq_pin_list **last, *entry;
+ struct irq_pin_list *entry;
/* don't allow duplicates */
- last = >irq_2_pin;
- for_each_irq_pin(entry, cfg->irq_2_pin) {
+ for_each_irq_pin(entry, cfg->irq_2_pin)
if (entry->apic == apic && entry->pin == pin)
return 0;
- last = >next;
- }
entry = alloc_irq_pin_list(node);
if (!entry) {
@@ -439,7 +442,7 @@ static int __add_pin_to_irq_node(struct irq_cfg *cfg, int
node, int apic, int pi
entry->apic = apic;
entry->pin = pin;
- *last = entry;
+ list_add_tail(>list, >irq_2_pin);
return 0;
}
@@ -1622,8 +1625,7 @@ __apicdebuginit(void) print_IO_APICs(void)
cfg = irq_get_chip_data(irq);
if (!cfg)
continue;
- entry = cfg->irq_2_pin;
- if (!entry)
+ if (list_empty(>irq_2_pin))
continue;
printk(KERN_DEBUG "IRQ%d ", irq);
for_each_irq_pin(entry, cfg->irq_2_pin)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/28] x86, irq: Support ioapic controller hotplug
Hi, Intel cpu (from IVB) include cpu cores, mem controller, and IIO. When hotplug cpu physically, it will involve cpu hotplug, mem hotplug, and pci root hotplug. IIO includes pci host bridge, ioapic controller and iommu etc. pci devices will need to use ioapic and iommu. So to make pci root bus hotplug working, we need ioapic hotplug support. Now ioapics are with ACPI MADT table. During booting, kernel will parse MADT and put info into ioapic arrays. Also Bjorn added one pci device based driver, but it is not wired in yet, as it need to call acpi_register_ioapic, and that is TBD. This patchset will 1. extend genirq to support reserve/alloc_reserved method. because we want irqs for one ioapic controller to be linear mapping to the gsi range. 2. change ioapic array operation code so we could insert new ioapic and remove one leave the blank slot. 3. record irq_base in gsi_config in ioapic struct, and use it to convert gsi to irq for pci device using that ioapic controller 4. make static ioapic path (from MADT) use same code as hot-add path, with reserve/alloc_reserved method. 5. change ioapic add/remove to use acpi way, as that is only needed when pci root bus hotplug. 6. also support the case that ioapic controller is hiding in pci config space or ioapic address is not managed by pci reallocation subsys. Also include some cleanups 1. print MSI-X clearly in /proc/interrupts and dmesg. 2. convert ioapic irq_2_pin to be generic list. It is based on linus's tree of 2013/08/10 aka v3.11-rc4. could get them from: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-irq -v3: split last patch to 4 patches per request from Bjorn. drop one patch that will put pci device name in proc/interrupts update changelog. -v4: address review from tglx, change to realloc to alloc_reserved. separate x86 code and core code into different patches. Yinghai Lu (28): genirq: Split __irq_reserve_irqs from irq_alloc_descs genirq: Add irq_alloc_reserved_desc() genirq: Do not free unallocated irq descriptors x86, irq: Change irq_remap_modify_chip_defaults() to static x86, irq: Modify irq chip once for irq remapping x86, irq: Show MSI-X clearly in debug message x86, irq: Show MSI-X in /proc/interrupt x86, irq: Make dmar_msi/hpet_msi irq_chip name consistent ia64, irq: Add dummy create_irq_nr() iommu, irq: Allocate irq_desc for dmar_msi with local node x86, irq: Kill create_irq() x86, irq: Convert irq_2_pin list to generic list x86, irq: Add alloc_reserved_irq_and_cfg_at() x86, irq: Move down arch_early_irq_init() x86, irq: Split out alloc_ioapic_save_registers() xen, irq: Call irq_alloc_reserved_desc_at() at first x86, irq: Reserve irq range and alloc_reserved for booting path x86, irq: Add ioapic_gsi_to_irq x86, irq: Add for_each_ioapic helper x86, irq: More strict checking about registering ioapic x86, irq: Make mp_register_ioapic handle hot-added ioapic x86, irq: Add mp_unregister_ioapic to handle hot-remove ioapic x86, ioapic: Find usable ioapic id for 64bit. x86: Move declaration for mp_register_ioapic() PCI, x86: Make ioapic hotplug support built-in PCI, x86, ACPI: Link acpi ioapic register to ioapic PCI, x86, ACPI: Enable ioapic hotplug support with acpi host bridge. PCI, x86, ACPI: get ioapic address from acpi device arch/ia64/kernel/irq_ia64.c | 10 + arch/x86/include/asm/hw_irq.h| 2 +- arch/x86/include/asm/io_apic.h | 13 + arch/x86/include/asm/irq_remapping.h | 14 +- arch/x86/include/asm/mpspec.h| 21 +- arch/x86/kernel/acpi/boot.c | 32 +-- arch/x86/kernel/apic/apic.c | 9 +- arch/x86/kernel/apic/io_apic.c | 480 +-- arch/x86/kernel/devicetree.c | 2 +- drivers/acpi/pci_root.c | 4 + drivers/iommu/amd_iommu_init.c | 2 +- drivers/iommu/dmar.c | 2 +- drivers/iommu/intel_irq_remapping.c | 2 +- drivers/iommu/irq_remapping.c| 18 +- drivers/pci/Kconfig | 3 +- drivers/pci/ioapic.c | 229 - drivers/xen/events.c | 8 +- include/linux/irq.h | 4 + include/linux/pci-acpi.h | 8 + kernel/irq/irqdesc.c | 80 -- 20 files changed, 679 insertions(+), 264 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 01/28] genirq: Split __irq_reserve_irqs from irq_alloc_descs
irq_alloc_descs and irq_reserve_irqs are almost the same.
Separate code out to __irq_reserved_irqs, and other two reuse
__irq_reserve_irqs.
We will use __irq_reserve_irqs for coming ioapic hotplug support.
-v2: fix func docbook related comments, pointed out by tglx.
Signed-off-by: Yinghai Lu
Cc: Alexander Gordeev
Reviewed-by: Alexander Gordeev
---
include/linux/irq.h | 1 +
kernel/irq/irqdesc.c | 54 ++--
2 files changed, 32 insertions(+), 23 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index f04d3ba..8c46cb2 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -611,6 +611,7 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned
int cnt, int node,
void irq_free_descs(unsigned int irq, unsigned int cnt);
int irq_reserve_irqs(unsigned int from, unsigned int cnt);
+int __irq_reserve_irqs(int irq, unsigned int from, unsigned int cnt);
static inline void irq_free_desc(unsigned int irq)
{
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 192a302..a151db6 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -340,18 +340,15 @@ void irq_free_descs(unsigned int from, unsigned int cnt)
EXPORT_SYMBOL_GPL(irq_free_descs);
/**
- * irq_alloc_descs - allocate and initialize a range of irq descriptors
- * @irq: Allocate for specific irq number if irq >= 0
+ * __irq_reserve_irqs - reserve a range of irqs
+ * @irq: Reserve for specific irq number if irq >= 0
* @from: Start the search from this irq number
- * @cnt: Number of consecutive irqs to allocate.
- * @node: Preferred node on which the irq descriptor should be allocated
- * @owner: Owning module (can be NULL)
+ * @cnt: Number of consecutive irqs to reserve.
*
* Returns the first irq number or error code
*/
int __ref
-__irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
- struct module *owner)
+__irq_reserve_irqs(int irq, unsigned int from, unsigned int cnt)
{
int start, ret;
@@ -369,7 +366,7 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned int
cnt, int node,
start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,
from, cnt, 0);
ret = -EEXIST;
- if (irq >=0 && start != irq)
+ if (irq >= 0 && start != irq)
goto err;
if (start + cnt > nr_irqs) {
@@ -380,12 +377,36 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned
int cnt, int node,
bitmap_set(allocated_irqs, start, cnt);
mutex_unlock(_irq_lock);
- return alloc_descs(start, cnt, node, owner);
+ return start;
err:
mutex_unlock(_irq_lock);
return ret;
}
+
+/**
+ * __irq_alloc_descs - allocate and initialize a range of irq descriptors
+ * @irq: Allocate for specific irq number if irq >= 0
+ * @from: Start the search from this irq number
+ * @cnt: Number of consecutive irqs to allocate.
+ * @node: Preferred node on which the irq descriptor should be allocated
+ * @owner: Owning module (can be NULL)
+ *
+ * Returns the first irq number or error code
+ */
+int __ref
+__irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
+ struct module *owner)
+{
+ int start;
+
+ start = __irq_reserve_irqs(irq, from, cnt);
+
+ if (start < 0)
+ return start;
+
+ return alloc_descs(start, cnt, node, owner);
+}
EXPORT_SYMBOL_GPL(__irq_alloc_descs);
/**
@@ -397,20 +418,7 @@ EXPORT_SYMBOL_GPL(__irq_alloc_descs);
*/
int irq_reserve_irqs(unsigned int from, unsigned int cnt)
{
- unsigned int start;
- int ret = 0;
-
- if (!cnt || (from + cnt) > nr_irqs)
- return -EINVAL;
-
- mutex_lock(_irq_lock);
- start = bitmap_find_next_zero_area(allocated_irqs, nr_irqs, from, cnt,
0);
- if (start == from)
- bitmap_set(allocated_irqs, start, cnt);
- else
- ret = -EEXIST;
- mutex_unlock(_irq_lock);
- return ret;
+ return __irq_reserve_irqs(from, from, cnt);
}
/**
--
1.8.1.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 06/28] x86, irq: Show MSI-X clearly in debug message
Print out exact MSI or MSI-X instead of MSI/MSI-X. Signed-off-by: Yinghai Lu Cc: Joerg Roedel Cc: Konrad Rzeszutek Wilk Cc: Sebastian Andrzej Siewior --- arch/x86/kernel/apic/io_apic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index eda56ad..119fdf8 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -3125,7 +3125,8 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, irq_set_chip_and_handler_name(irq, chip, handle_edge_irq, "edge"); - dev_printk(KERN_DEBUG, >dev, "irq %d for MSI/MSI-X\n", irq); + dev_printk(KERN_DEBUG, >dev, "irq %d for MSI%s\n", irq, +msidesc->msi_attrib.is_msix ? "-X" : ""); return 0; } -- 1.8.1.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 5/7] powerpc/perf: Define big-endian version of perf_mem_data_src
On Sat, 10 Aug 2013, Sukadev Bhattiprolu wrote: > > include/uapi/linux/perf_event.h | 55 > +++ > 1 files changed, 55 insertions(+), 0 deletions(-) > +#define __PERF_LE1234 > +#define __PERF_BE4321 > + > +#if defined(__KERNEL__) I could be wrong, but I thought files under uapi weren't supposed to contain __KERNEL__ code. Wasn't that the whole point of uapi? Also having the perf_event interface depend on endianess just seems like a complicated mess. Can't we just declare the interface to be a certain endianess and have the kernel byte-swap as necessary? 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
On Sat, 10 Aug 2013, Thomas Richter wrote: > Sorry, need to look further. I replaced ehci-pci from 2.6.31.14, and > yenta_socket as well. No changes were necessary. Also replaced ehci-hcd, Do you mean that you took the source code for ehci-hcd from the 2.6.31 kernel, copied it into the source directory for the 2.6.32 kernel, and built it there? > but that required two minor changes because in 2.6.32, apparently, one > hardware related structure was pulled out of the ehci structure. > > Still did not make any difference, still locks up. > > What's the next module up in the call chain I should be looking at? Have you tried comparing a usbmon trace from 2.6.31 with a comparable trace from 2.6.32? I doubt there will be any important differences, but you never know until you try. If the two traces are the same, that rules out everything in the USB and SCSI stacks except for ehci-hcd, and you have already ruled that out. Alan Stern -- 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
On Sat, 10 Aug 2013, Josep Lladonosa wrote: > Hello, > > Have you tried to wait for 5 minutes? It could also be related to it > what happens to my kernel 3.11.0-rc4 (and rc3) and USB > > I plug the drive. Only after 5 minutes of high-speed of USb bus, it mounts. Your experience is not related to Thomas's problem. It can be fixed by applying this patch: http://marc.info/?l=linux-usb=137523956310060=2 Alan Stern -- 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/
OMAP device tree maintainance (was Re: [PATCH v2] N900: add device tree)
Hi! > > [I wonder if this is clean-enough cause for "trivial in resubmit > > mode?] > > On Sat, 10 Aug 2013, Belisko Marek wrote: > > > Same for gta04 (omap3 based device) [1]. > > It was send upstream 2 times and second time there is no reply from > > 1.3.2013. > > Hi guys, > > once I am able to match signoffs in the patches to MAINTAINERS, I can take > those through trivial.git in "re-transmission mode" (or feeeding those > thgough akpm si an option as well). > > Please just send the patches to me in a new thread properly with all the > Acks/Signoffs, and mark those appropriately (i.e. maintainer that would > normally push this upstream desurfaced). Mail sent (just to you, to keep mail volume down). I noticed two non-delivery reports in my INBOX; seems Benoit disappeared rather permanently: ... If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host cluster5.us.messagelabs.com[216.82.250.99] said: 550 Invalid recipient (#5.1.1) (in reply to RCPT TO command) ...so maybe MAINTAINERS file will need fixing? OMAP DEVICE TREE SUPPORT M: Benoît Cousson M: Tony Lindgren L: linux-o...@vger.kernel.org L: devicet...@vger.kernel.org S: Maintained F: arch/arm/boot/dts/*omap* F: arch/arm/boot/dts/*am3* :-(. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] kbuild: Increase kallsyms max symbol length
From: Joe Mario
[AK: This seems like a ticking time bomb even without LTO,
so should be merged now. It causes very weird problems.
Thanks to Joe for tracking them down.]
With the added postfixes that LTO adds for local
symbols, the longest name in the kernel overflows
the namebuf[KSYM_NAME_LEN] array by two bytes. That name is:
__pci_fixup_resumePCI_VENDOR_ID_SERVERWORKSPCI_DEVICE_ID_SERVERWORKS_HT1000SBquirk_disable_broadcom_boot_interrupt.1488004.672802
Double the max symbol name length.
Signed-off-by: Andi Kleen
---
include/linux/kallsyms.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 6883e19..711a50f 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -9,7 +9,7 @@
#include
#include
-#define KSYM_NAME_LEN 128
+#define KSYM_NAME_LEN 256
#define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s]") + (KSYM_NAME_LEN - 1) + \
2*(BITS_PER_LONG*3/10) + (MODULE_NAME_LEN - 1) + 1)
--
1.8.3.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/
[PATCH 2/3] Kbuild: Handle longer symbols in kallsyms.c
From: Andi Kleen
Also warn for too long symbols
Signed-off-by: Andi Kleen
---
scripts/kallsyms.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 6940f00..e5af4c5 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -27,7 +27,7 @@
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof(arr[0]))
#endif
-#define KSYM_NAME_LEN 128
+#define KSYM_NAME_LEN 256
struct sym_entry {
unsigned long long addr;
@@ -118,6 +118,12 @@ static int read_symbol(FILE *in, struct sym_entry *s)
fprintf(stderr, "Read error or end of file.\n");
return -1;
}
+ if (strlen(str) > KSYM_NAME_LEN) {
+ fprintf(stderr, "Symbol %s too long for kallsyms.\n"
+"Please increae KSYM_NAME_LEN both in kernel
and kallsyms.c",
+ str);
+ return -1;
+ }
sym = str;
/* skip prefix char */
--
1.8.3.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/
[PATCH 3/3] kprobes: Use KSYM_NAME_LEN to size identifier buffers
From: Joe Mario
Use KSYM_NAME_LEN to size identifier buffers, so that it can
be easier increased.
Cc: ana...@in.ibm.com
Signed-off-by: Joe Mario
Signed-off-by: Andi Kleen
---
kernel/kprobes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 6e33498..e174daf 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2083,7 +2083,7 @@ static int __init init_kprobes(void)
{
int i, err = 0;
unsigned long offset = 0, size = 0;
- char *modname, namebuf[128];
+ char *modname, namebuf[KSYM_NAME_LEN];
const char *symbol_name;
void *addr;
struct kprobe_blackpoint *kb;
@@ -2209,7 +2209,7 @@ static int __kprobes show_kprobe_addr(struct seq_file
*pi, void *v)
const char *sym = NULL;
unsigned int i = *(loff_t *) v;
unsigned long offset = 0;
- char *modname, namebuf[128];
+ char *modname, namebuf[KSYM_NAME_LEN];
head = _table[i];
preempt_disable();
--
1.8.3.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/
[PATCH] turbostat: Check return value of fscanf
Some systems declare fscanf with the warn_unused_result attribute. On
such systems, turbostat generates the following warnings:
turbostat.c: In function 'get_core_id':
turbostat.c:1203:8: warning: ignoring return value of 'fscanf', declared with
attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'get_physical_package_id':
turbostat.c:1186:8: warning: ignoring return value of 'fscanf', declared with
attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'cpu_is_first_core_in_package':
turbostat.c:1169:8: warning: ignoring return value of 'fscanf', declared with
attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'cpu_is_first_sibling_in_core':
turbostat.c:1148:8: warning: ignoring return value of 'fscanf', declared with
attribute warn_unused_result [-Wunused-result]
Fix these by checking the return value of those four calls to fscanf.
Signed-off-by: Josh Triplett
---
tools/power/x86/turbostat/turbostat.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index dc30f1b..514adba 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1167,7 +1167,10 @@ int cpu_is_first_sibling_in_core(int cpu)
perror(path);
exit(1);
}
- fscanf(filep, "%d", _cpu);
+ if (fscanf(filep, "%d", _cpu) != 1) {
+ perror(path);
+ exit(1);
+ }
fclose(filep);
return (cpu == first_cpu);
}
@@ -1188,7 +1191,10 @@ int cpu_is_first_core_in_package(int cpu)
perror(path);
exit(1);
}
- fscanf(filep, "%d", _cpu);
+ if (fscanf(filep, "%d", _cpu) != 1) {
+ perror(path);
+ exit(1);
+ }
fclose(filep);
return (cpu == first_cpu);
}
@@ -1205,7 +1211,10 @@ int get_physical_package_id(int cpu)
perror(path);
exit(1);
}
- fscanf(filep, "%d", );
+ if (fscanf(filep, "%d", ) != 1) {
+ perror(path);
+ exit(1);
+ }
fclose(filep);
return pkg;
}
@@ -1222,7 +1231,10 @@ int get_core_id(int cpu)
perror(path);
exit(1);
}
- fscanf(filep, "%d", );
+ if (fscanf(filep, "%d", ) != 1) {
+ perror(path);
+ exit(1);
+ }
fclose(filep);
return core;
}
--
1.8.4.rc1
--
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] turbostat: Use GCC's CPUID functions to support PIC
turbostat uses inline assembly to call cpuid. On 32-bit x86, on systems
that have certain security features enabled by default that make -fPIC
the default, this causes a build error:
turbostat.c: In function ‘check_cpuid’:
turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’
asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
^
GCC provides a header cpuid.h, containing a __get_cpuid function that
works with both PIC and non-PIC. (On PIC, it saves and restores ebx
around the cpuid instruction.) Use that instead.
Signed-off-by: Josh Triplett
Cc: sta...@vger.kernel.org
---
CCing stable because this causes a build failure on some 32-bit targets.
tools/power/x86/turbostat/turbostat.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index b10b8d2..dc30f1b 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
char *proc_stat = "/proc/stat";
unsigned int interval_sec = 5; /* set with -i interval_sec */
@@ -1894,7 +1895,7 @@ void check_cpuid()
eax = ebx = ecx = edx = 0;
- asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) :
"a" (0));
+ __get_cpuid(0, _level, , , );
if (ebx == 0x756e6547 && edx == 0x49656e69 && ecx == 0x6c65746e)
genuine_intel = 1;
@@ -1903,7 +1904,7 @@ void check_cpuid()
fprintf(stderr, "CPUID(0): %.4s%.4s%.4s ",
(char *), (char *), (char *));
- asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
+ __get_cpuid(1, , , , );
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
@@ -1925,7 +1926,7 @@ void check_cpuid()
* This check is valid for both Intel and AMD.
*/
ebx = ecx = edx = 0;
- asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) :
"a" (0x8000));
+ __get_cpuid(0x8000, _level, , , );
if (max_level < 0x8007) {
fprintf(stderr, "CPUID: no invariant TSC (max_level 0x%x)\n",
max_level);
@@ -1936,7 +1937,7 @@ void check_cpuid()
* Non-Stop TSC is advertised by CPUID.EAX=0x8007: EDX.bit8
* this check is valid for both Intel and AMD
*/
- asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a"
(0x8007));
+ __get_cpuid(0x8007, , , , );
has_invariant_tsc = edx & (1 << 8);
if (!has_invariant_tsc) {
@@ -1949,7 +1950,7 @@ void check_cpuid()
* this check is valid for both Intel and AMD
*/
- asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a"
(0x6));
+ __get_cpuid(0x6, , , , );
has_aperf = ecx & (1 << 0);
do_dts = eax & (1 << 0);
do_ptm = eax & (1 << 6);
--
1.8.4.rc1
--
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] turbostat: Don't attempt to printf an off_t with %zx
turbostat uses the format %zx to print an off_t. However, %zx wants a
size_t, not an off_t. On 32-bit targets, those refer to different
types, potentially even with different sizes. Use %llx and a cast
instead, since printf does not have a length modifier for off_t.
Without this patch, when compiling for a 32-bit target:
turbostat.c: In function 'get_msr':
turbostat.c:231:3: warning: format '%zx' expects argument of type 'size_t', but
argument 4 has type 'off_t' [-Wformat]
Signed-off-by: Josh Triplett
---
tools/power/x86/turbostat/turbostat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index 5bf4a67..b10b8d2 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -230,7 +230,7 @@ int get_msr(int cpu, off_t offset, unsigned long long *msr)
close(fd);
if (retval != sizeof *msr) {
- fprintf(stderr, "%s offset 0x%zx read failed\n", pathname,
offset);
+ fprintf(stderr, "%s offset 0x%llx read failed\n", pathname,
(unsigned long long)offset);
return -1;
}
--
1.8.4.rc1
--
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] turbostat: Don't put unprocessed uapi headers in the include path
turbostat's Makefile puts arch/x86/include/uapi/ in the include path, so that it can include from it. It isn't in general safe to include even uapi headers directly from the kernel tree without processing them through scripts/headers_install.sh, but asm/msr.h happens to work. However, that include path can break with some versions of system headers, by overriding some system headers with the unprocessed versions directly from the kernel source. For instance: In file included from /build/x86-generic/usr/include/bits/sigcontext.h:28:0, from /build/x86-generic/usr/include/signal.h:339, from /build/x86-generic/usr/include/sys/wait.h:31, from turbostat.c:27: ../../../../arch/x86/include/uapi/asm/sigcontext.h:4:28: fatal error: linux/compiler.h: No such file or directory This occurs because the system bits/sigcontext.h on that build system includes , and asm/sigcontext.h in the kernel source includes , which scripts/headers_install.sh would have filtered out. Since turbostat really only wants a single header, just include that one header rather than putting an entire directory of kernel headers on the include path. In the process, switch from msr.h to msr-index.h, since turbostat just wants the MSR numbers. Signed-off-by: Josh Triplett Cc: sta...@vger.kernel.org --- CCing this to stable because it fixes a broken build on some systems. Applies as far back as 3.8. tools/power/x86/turbostat/Makefile| 2 +- tools/power/x86/turbostat/turbostat.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile index f09641d..d1b3a36 100644 --- a/tools/power/x86/turbostat/Makefile +++ b/tools/power/x86/turbostat/Makefile @@ -5,7 +5,7 @@ DESTDIR := turbostat : turbostat.c CFLAGS += -Wall -CFLAGS += -I../../../../arch/x86/include/uapi/ +CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"' %: %.c @mkdir -p $(BUILD_OUTPUT) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index fe70207..5bf4a67 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -20,7 +20,7 @@ */ #define _GNU_SOURCE -#include +#include MSRHEADER #include #include #include -- 1.8.4.rc1 -- 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 Aug 9 (staging/ozwpan)
On 08/10/13 15:15, Randy Dunlap wrote: > On 08/08/13 23:15, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20130808: >> >> *crickets* >> > > on i386: > > ERROR: "__divdi3" [drivers/staging/ozwpan/ozwpan.ko] undefined! > 2 occurrences of this in oz_hcd_heartbeat(). > > > Apologies if this has already been reported/fixed. > -- ~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: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
On 08/10/2013 11:51 AM, Linus Torvalds wrote: > Note that you still want the *test* to be done in C code, because together > with "unlikely()" you'd likely do pretty close to optimal code > generation, and hiding the decrement and test and conditional jump in > asm you wouldn't get the proper instruction scheduling and branch > following that gcc does. How much instruction scheduling can gcc actually do given that there is a barrier involved? I guess some on the RISC architectures which need load/subtract/store... -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] arch/arm/mach-pxa/stargate2.c: use ARRAY_AND_SIZE consistently
ARRAY_AND_SIZE() macro is horrible, and I would like it if it were removed. What I meant before was just that probably people will probably complain if we try to remove it. regards, dan carpenter -- 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] mfd: Add support for COMe-bHL6 and COMe-cTH6 to Kontron PLD driver
On Fri, Aug 09, 2013 at 05:33:43PM +0200, Michael Brunner wrote:
> This patch adds DMI system IDs for the new Kontron modules COMe-bHL6 and
> COMe-cTH6 to the Kontron PLD driver.
>
> Signed-off-by: Michael Brunner
Acked-by: Kevin Strasser
> ---
> drivers/mfd/kempld-core.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c
> index 686a456..ee28e76 100644
> --- a/drivers/mfd/kempld-core.c
> +++ b/drivers/mfd/kempld-core.c
> @@ -413,6 +413,15 @@ static struct platform_driver kempld_driver = {
>
> static struct dmi_system_id __initdata kempld_dmi_table[] = {
> {
> + .ident = "BHL6",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
> + DMI_MATCH(DMI_BOARD_NAME, "COMe-bHL6"),
> + },
> + .driver_data = (void *)_platform_data_generic,
> + .callback = kempld_create_platform_device,
> + },
> + {
> .ident = "CCR2",
> .matches = {
> DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
> @@ -596,6 +605,15 @@ static struct dmi_system_id __initdata
> kempld_dmi_table[] = {
> .driver_data = (void *)_platform_data_generic,
> .callback = kempld_create_platform_device,
> },
> + {
> + .ident = "UTH6",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
> + DMI_MATCH(DMI_BOARD_NAME, "COMe-cTH6"),
> + },
> + .driver_data = (void *)_platform_data_generic,
> + .callback = kempld_create_platform_device,
> + },
> {}
> };
> MODULE_DEVICE_TABLE(dmi, kempld_dmi_table);
--
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] gpio: Fix platform driver name in Kontron PLD GPIO driver
On Fri, Aug 09, 2013 at 05:33:06PM +0200, Michael Brunner wrote:
> This patch changes the driver name to be consistent with the name that
> is registered as cell name in the MFD driver. Otherwise the driver won't
> load.
>
> Signed-off-by: Michael Brunner
Acked-by: Kevin Strasser
> ---
> drivers/gpio/gpio-kempld.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-kempld.c b/drivers/gpio/gpio-kempld.c
> index 1bdc3a2..d3ed563 100644
> --- a/drivers/gpio/gpio-kempld.c
> +++ b/drivers/gpio/gpio-kempld.c
> @@ -210,7 +210,7 @@ static int kempld_gpio_remove(struct
> platform_device *pdev)
> static struct platform_driver kempld_gpio_driver = {
> .driver = {
> - .name = "gpio-kempld",
> + .name = "kempld-gpio",
> .owner = THIS_MODULE,
> },
> .probe = kempld_gpio_probe,
--
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] gpio: Fix bit masking in Kontron PLD GPIO driver
On Fri, Aug 09, 2013 at 05:33:26PM +0200, Michael Brunner wrote: > This patch fixes the bit masking within the GPIO driver. The masking is > basically done twice which causes the wrong GPIOs to be addressed. > > Signed-off-by: Michael Brunner Acked-by: Kevin Strasser > --- > drivers/gpio/gpio-kempld.c | 24 +--- > 1 file changed, 9 insertions(+), 15 deletions(-) > > diff --git a/drivers/gpio/gpio-kempld.c b/drivers/gpio/gpio-kempld.c > index d3ed563..6118b66 100644 > --- a/drivers/gpio/gpio-kempld.c > +++ b/drivers/gpio/gpio-kempld.c > @@ -46,9 +46,9 @@ static void kempld_gpio_bitop(struct kempld_device_data > *pld, > > status = kempld_read8(pld, reg); > if (val) > - status |= (1 << bit); > + status |= KEMPLD_GPIO_MASK(bit); > else > - status &= ~(1 << bit); > + status &= ~KEMPLD_GPIO_MASK(bit); > kempld_write8(pld, reg, status); > } > > @@ -60,7 +60,7 @@ static int kempld_gpio_get_bit(struct kempld_device_data > *pld, u8 reg, u8 bit) > status = kempld_read8(pld, reg); > kempld_release_mutex(pld); > > - return !!(status & (1 << bit)); > + return !!(status & KEMPLD_GPIO_MASK(bit)); > } > > static int kempld_gpio_get(struct gpio_chip *chip, unsigned offset) > @@ -69,8 +69,7 @@ static int kempld_gpio_get(struct gpio_chip *chip, unsigned > offset) > = container_of(chip, struct kempld_gpio_data, chip); > struct kempld_device_data *pld = gpio->pld; > > - return kempld_gpio_get_bit(pld, KEMPLD_GPIO_LVL_NUM(offset), > - KEMPLD_GPIO_MASK(offset)); > + return kempld_gpio_get_bit(pld, KEMPLD_GPIO_LVL_NUM(offset), offset); > } > > static void kempld_gpio_set(struct gpio_chip *chip, unsigned offset, int > value) > @@ -80,8 +79,7 @@ static void kempld_gpio_set(struct gpio_chip *chip, > unsigned offset, int value) > struct kempld_device_data *pld = gpio->pld; > > kempld_get_mutex(pld); > - kempld_gpio_bitop(pld, KEMPLD_GPIO_LVL_NUM(offset), > - KEMPLD_GPIO_MASK(offset), value); > + kempld_gpio_bitop(pld, KEMPLD_GPIO_LVL_NUM(offset), offset, value); > kempld_release_mutex(pld); > } > > @@ -92,8 +90,7 @@ static int kempld_gpio_direction_input(struct gpio_chip > *chip, unsigned offset) > struct kempld_device_data *pld = gpio->pld; > > kempld_get_mutex(pld); > - kempld_gpio_bitop(pld, KEMPLD_GPIO_DIR_NUM(offset), > - KEMPLD_GPIO_MASK(offset), 0); > + kempld_gpio_bitop(pld, KEMPLD_GPIO_DIR_NUM(offset), offset, 0); > kempld_release_mutex(pld); > > return 0; > @@ -107,10 +104,8 @@ static int kempld_gpio_direction_output(struct gpio_chip > *chip, unsigned offset, > struct kempld_device_data *pld = gpio->pld; > > kempld_get_mutex(pld); > - kempld_gpio_bitop(pld, KEMPLD_GPIO_LVL_NUM(offset), > - KEMPLD_GPIO_MASK(offset), value); > - kempld_gpio_bitop(pld, KEMPLD_GPIO_DIR_NUM(offset), > - KEMPLD_GPIO_MASK(offset), 1); > + kempld_gpio_bitop(pld, KEMPLD_GPIO_LVL_NUM(offset), offset, value); > + kempld_gpio_bitop(pld, KEMPLD_GPIO_DIR_NUM(offset), offset, 1); > kempld_release_mutex(pld); > > return 0; > @@ -122,8 +117,7 @@ static int kempld_gpio_get_direction(struct gpio_chip > *chip, unsigned offset) > = container_of(chip, struct kempld_gpio_data, chip); > struct kempld_device_data *pld = gpio->pld; > > - return kempld_gpio_get_bit(pld, KEMPLD_GPIO_DIR_NUM(offset), > - KEMPLD_GPIO_MASK(offset)); > + return kempld_gpio_get_bit(pld, KEMPLD_GPIO_DIR_NUM(offset), offset); > } > > static int kempld_gpio_pincount(struct kempld_device_data *pld) -- 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 Aug 9 (staging/ozwpan)
On 08/08/13 23:15, Stephen Rothwell wrote: > Hi all, > > Changes since 20130808: > > *crickets* > on i386: ERROR: "__divdi3" [drivers/staging/ozwpan/ozwpan.ko] undefined! Apologies if this has already been reported/fixed. -- ~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: [ 00/25] 3.4.57-stable review
On 08/09/2013 07:56 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.57 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Aug 11 01:33:13 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.57-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.89, 3.4.56 and 3.10.5 Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5: (3.4.57-rc1, 3.10.6-rc1) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1) dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1) Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.10.y blackfin: defconfig passed on all c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.10.y mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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: [ 00/22] 3.0.90-stable review
On 08/09/2013 08:00 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.90 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Aug 11 01:37:07 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.90-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.89, 3.4.56 and 3.10.5 Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5: (3.4.57-rc1, 3.10.6-rc1) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1) dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1) Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.10.y blackfin: defconfig passed on all c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.10.y mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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: [ 000/102] 3.10.6-stable review
On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote: > On Fri, Aug 09, 2013 at 02:42:24PM +, Shuah Khan wrote: >> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote: >>> This is the start of the stable review cycle for the 3.10.6 release. >>> There are 102 patches in this series, all will be posted as a response >>> to this one. If anyone has any issues with these being applied, please >>> let me know. >>> >>> Responses should be made by Sun Aug 11 01:46:31 UTC 2013. >>> Anything received after that time might be too late. >>> >>> The whole patch series can be found in one patch at: >>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz >>> and the diffstat can be found below. >>> >>> thanks, >>> >>> greg k-h >>> > Patches applied to 3.0.89, 3.4.56 and 3.10.5 Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5: (3.4.57-rc1, 3.10.6-rc1) HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics: (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1) dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1) Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.10.y blackfin: defconfig passed on all c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.10.y mips: defconfig passed on all mipsel: defconfig passed on all powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface
Arnd Bergmann wrote: GOAL The goal of this patch was to make it possible to configure daemons using simple file IO. The litmus test for this is that commands like these should be possible cat < /var/daemons/wpa_supplicant/use_channel echo 5 >/var/daemons/wpa_supplicant/use_channel If you want to have that behavior, I think the best way to do it would be new file system that combines aspects of tmpfs and debugfs, letting users with write access to the mount point (or a directory under it) create subdirectories and files using regular unix permission handling. You would then always use the file_operations that you defined for your chardev but use that with inode_operations similar to tmpfs. THANKS! It would still be a kernel patch and still require root to set up but so would FUSE and your approach might be much lighter weight. thanks Bob Smith -- 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 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface
On Saturday 10 August 2013, Bob Smith wrote: > GOAL > The goal of this patch was to make it possible to configure > daemons using simple file IO. The litmus test for this is > that commands like these should be possible > cat < /var/daemons/wpa_supplicant/use_channel > echo 5 >/var/daemons/wpa_supplicant/use_channel > > Yes, there are many other ways to configure a daemon but > none with the simplicity and grace of file IO. For proof > of this I point to procfs and sysfs. I'll try to keep out of the discussion about whether or not another IPC mechanism with your desired semantics would be good to have in the kernel, but one comment about implementing it: If you want to have that behavior, I think the best way to do it would be new file system that combines aspects of tmpfs and debugfs, letting users with write access to the mount point (or a directory under it) create subdirectories and files using regular unix permission handling. You would then always use the file_operations that you defined for your chardev but use that with inode_operations similar to tmpfs. Arnd -- 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] udev: fail firmware loading immediately if no search path is defined
On Sat, Aug 10, 2013 at 11:00 PM, Tom Gundersen wrote:
> It would be simple enough to add an udev rule to just print 'ignoring
> firmware event' to the logs.
This and I guess:
SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
would also just cancel the request at the same time without any other
code needed.
The udev firmware support just a configure option, just like the
kernel has them. So distributions should enable it in udev and the
kernel if they need it.
We simply cannot coordinate the defaults of systemd and the kernel
because the rules of the kernel are different. The kernel does "keep
defaults like stuff has been in the past" and udev does "make default
what makes the most sense on current systems".
> We should really ignore the event though, and
> not cancel it. Not sure if this is something we want upstream (after all,
> there are plenty of situations where we don't warn if the recommendations in
> the README file are not followed), or if distros and whoever wants it should
> ship that themselves. I'll leave that for Kay to decide.
The proper fix is that userspace firmware should be disabled in the
kernel for new systems, and kept enabled only for old systems. Old
systems need to enable a new udev version to support firmware loading.
There are currently broken in-kernel mis-users of the firmware
interface that use the firmware interface but disable uevents, they
still pull-in the user interface of the firmware loader. If nobody
wants to fix them, the code for the common users of the firmware
loader should at least get rid of the userspace fallback to call out
to userspace. At that point the udev configure option would not matter
any more.
> Lastly, note that the plan is to drop all the firmware code from udev in the
> not too distant future, so it doesn't really maker much sense to add new
> functionality to that at this point.
Right, I think all is fine. It's something that people can control
with the kernel and udev configuration options. It's just that the
defaults of the kernel and udev don't match at the moment, because
they have different policies of setting default values.
Kay
--
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 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface
richard -rw- weinberger wrote: GOAL The goal of this patch was to make it possible to configure daemons using simple file IO. The litmus test for this is that commands like these should be possible cat < /var/daemons/wpa_supplicant/use_channel echo 5 >/var/daemons/wpa_supplicant/use_channel Yes, there are many other ways to configure a daemon but none with the simplicity and grace of file IO. For proof of this I point to procfs and sysfs. /me read the whole thread and still does get why you can't use CUSE. ...or AF_UNIX. Rightly or wrongly, my goal is pretty clear. I want to be able to use file IO to control a daemon. AF_UNIX doesn't help. CUSE/FUSE takes over main() and makes it very difficult to use select() and file descriptors. So it fails too for now. If you really have an use case which is not covered by CUSE, please fix CUSE. Yeah, if I proceed from here then modifying the user space parts of FUSE might be the best way to go. Sorry that it took so long to get to the point that my goals for the patch were clearly stated. As I say, I'm an EE who probably need more adult supervision. :) thanks Bob Smith -- 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/
Lieber Freund!!!
-- Lieber Freund!!! Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es ist wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (StandardBank PLC von Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was nicht in anspruch genommen worden ist, wo derzeit USD$18.5M (Achtzehn Million, Fünf Hundert Tausend, US Dollar) gutgeschrieben sind. Dieses Konto gehörte Herrn Peter Hartmann, der ein Kunde in unsere Bank war, der leider verstorben ist. Herr Hartmann war ein gebürtiger Deutscher. Damit es mir möglich ist dieses Geld $18,500,000 inanspruch zunehmen,benötige ich die zusammenarbeit eines Ausländischen Partners wie Sie,den ich als Verwandter und Erbe des verstorbenen Herrn Hartmann vorstellen kann,damit wir das Geld inanspruch nehmen können. Für diese Unterstützung erhalten Sie 30% der Erbschaftsumme und die restlichen 70% teile ich mirmit meinen zwei Arbeitskollegen, die mich bei dieser Transaktion ebenfalls unterstützen. Wenn Sie interessiert sind, können Sie mir bitte eine E-Mail schicken, damit ich Ihnen mehr Details zukommen lassen kann. N.B.BITTE SENDEN SIE MIR LEWIS AWELE ANTWORT ZU durch mein E-mail: ( banka...@aim.com ) fÜR VERTRAULICHEN GRUND. Schicken Sie keine POST ZU MEINEM BÜRO-E-MAIL. ( banka...@aim.com ) If you understand english,please kindly reply with english ( banka...@aim.com ) Mit freundlichen Grüßen Herr LEWIS AWELE -- 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/
My Good Friend..
My name is Mr.Wright Cain,a Christian from UK. I picked your email for inheritance of $2.5 Million US Dollars.Contact me for more details here is my Private E-mail Address: wrightc...@yahoo.com Thanks, Mr.Wright Cain -- 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 10/13] x86: Move cond resched for copy_{from,to}_user into low level code 64bit
On Sat, 10 August 2013 20:23:09 +0200, Borislav Petkov wrote: > > Sounds like the debug aspect and the preemption point addition need > to be sorf-of split into two different functions/macros and each used > separately. > > Something like keep the current might_sleep and have debug_sleep or > similar which does only __might_sleep without the resched... I would argue for using "might_sleep" for the debug variant. Before reading this thread I wasn't even aware of the non-debug aspect. After all, might_sleep naturally reads like some assertion. "might_preempt" for the non-debug version? "cond_preempt"? Jörn -- It is the mark of an educated mind to be able to entertain a thought without accepting it. -- Aristotle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] N900: add device tree
On Sat, 10 Aug 2013, Pavel Machek wrote: > [I wonder if this is clean-enough cause for "trivial in resubmit > mode?] On Sat, 10 Aug 2013, Belisko Marek wrote: > Same for gta04 (omap3 based device) [1]. > It was send upstream 2 times and second time there is no reply from 1.3.2013. Hi guys, once I am able to match signoffs in the patches to MAINTAINERS, I can take those through trivial.git in "re-transmission mode" (or feeeding those thgough akpm si an option as well). Please just send the patches to me in a new thread properly with all the Acks/Signoffs, and mark those appropriately (i.e. maintainer that would normally push this upstream desurfaced). -- Jiri Kosina SUSE Labs -- 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 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface
On Sat, Aug 10, 2013 at 10:08 PM, Bob Smith wrote: > Greg Kroah-Hartman wrote: >> >> Otherwise, to accept this code, I need to see a way that normal users >> can use it (i.e. no root or mknod), and that it can handle namespaces >> and the security interface that the kernel has to support. To do so >> otherwise would be unfair to users who expect such a thing. > > > Greg, I don't know the etiquette of the lkml but I think the > above means "no, go away". > > OK. > On my way out the door I'll give a recap and say thanks > > > GOAL > The goal of this patch was to make it possible to configure > daemons using simple file IO. The litmus test for this is > that commands like these should be possible > cat < /var/daemons/wpa_supplicant/use_channel > echo 5 >/var/daemons/wpa_supplicant/use_channel > > Yes, there are many other ways to configure a daemon but > none with the simplicity and grace of file IO. For proof > of this I point to procfs and sysfs. > > APPROACHES > Modifying name pipes was rejected as being too complex. > Modifying FUSE was rejected for the amount of effort needed. > The method chosen was to create a small character device > to pass the data between the client and the daemon. The > resulting code was small and simple but requires a device > node. > > CONCLUSION > Pseudo-ttys not withstanding, the kernel does not want > IPC mechanisms that require root privileges or mknod. > For this and other reasons this patch is rejected. > > > Greg, once again thanks for your patience in helping a > non-kernel guy through all of this. Thanks. /me read the whole thread and still does get why you can't use CUSE. ...or AF_UNIX. If you really have an use case which is not covered by CUSE, please fix CUSE. > bye > Bob Smith > > -- > 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/ -- 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: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
On 08/10/2013 11:51 AM, Linus Torvalds wrote: > That "kernel_stack" thing is actually getting the thread_info pointer, > and it doesn't get cached because gcc thinks the preempt_count value > might alias. This is just plain braindamaged. Somewhere on my list of things is to merge thread_info and task_struct and have a pointer to the unified structure. -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 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface
Greg Kroah-Hartman wrote: Otherwise, to accept this code, I need to see a way that normal users can use it (i.e. no root or mknod), and that it can handle namespaces and the security interface that the kernel has to support. To do so otherwise would be unfair to users who expect such a thing. Greg, I don't know the etiquette of the lkml but I think the above means "no, go away". OK. On my way out the door I'll give a recap and say thanks GOAL The goal of this patch was to make it possible to configure daemons using simple file IO. The litmus test for this is that commands like these should be possible cat < /var/daemons/wpa_supplicant/use_channel echo 5 >/var/daemons/wpa_supplicant/use_channel Yes, there are many other ways to configure a daemon but none with the simplicity and grace of file IO. For proof of this I point to procfs and sysfs. APPROACHES Modifying name pipes was rejected as being too complex. Modifying FUSE was rejected for the amount of effort needed. The method chosen was to create a small character device to pass the data between the client and the daemon. The resulting code was small and simple but requires a device node. CONCLUSION Pseudo-ttys not withstanding, the kernel does not want IPC mechanisms that require root privileges or mknod. For this and other reasons this patch is rejected. Greg, once again thanks for your patience in helping a non-kernel guy through all of this. Thanks. bye Bob Smith -- 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
Hi Josep, Perhaps both cases are related, and if you waited after those 5 minutes of resets, your pen would work fine... Have you checked your /var/log/messages after insertion of pen? My automount is under XFCE, not Gnome... ;) Unclear. Messages I get seem to make sense. First, it detects the insertion, then after five seconds or so, it creates the device file. If I mount this, I get the problem. So long, Thomas -- 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
On 10 August 2013 21:58, Josep Lladonosa wrote: > On 10 August 2013 21:52, Thomas Richter wrote: >> Hi Josep, >> >> >>> Have you tried to wait for 5 minutes? It could also be related to it >>> what happens to my kernel 3.11.0-rc4 (and rc3) and USB >>> >>> I plug the drive. Only after 5 minutes of high-speed of USb bus, it >>> mounts. I add that some usb pendrives mount immediately and some others don't... >> >> >> No, currently I don't even depend on gnome mounting it. I don't run a >> desktop. I just mount it manually in the single user mode with "mount" >> (eliminates variables that is). If I mount it, it first looks ok. Then I >> write a file on it. Still looks ok. Then I call "sync". That finally locks >> it up with the 2.6.32 kernel, not on 2.6.31. For the .32, it just sits >> there, after probably twenty seconds, it times out, complains that it can't >> write, then dies away. Works just nicely with the .31 kernel. >> > > Perhaps both cases are related, and if you waited after those 5 > minutes of resets, your pen would work fine... > Have you checked your /var/log/messages after insertion of pen? > > My automount is under XFCE, not Gnome... ;) > > Josep > > >> Thus, at this time, I guess I would need to know more about how a write >> reaches the ehci module, and how the configuration from there works. >> >> Sorry, but this isn't quite as simple as I thought. >> >> Thanks, >> Thomas > > > > -- > -- > Salutacions...Josep > -- -- -- Salutacions...Josep -- -- 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
On 10.08.2013 22:03, Josep Lladonosa wrote: I add that some usb pendrives mount immediately and some others don't... Nope, all the same here... None works. Pen drive, hard disk, does not matter. Greetings, Thomas -- 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
On 10 August 2013 21:52, Thomas Richter wrote: > Hi Josep, > > >> Have you tried to wait for 5 minutes? It could also be related to it >> what happens to my kernel 3.11.0-rc4 (and rc3) and USB >> >> I plug the drive. Only after 5 minutes of high-speed of USb bus, it >> mounts. > > > No, currently I don't even depend on gnome mounting it. I don't run a > desktop. I just mount it manually in the single user mode with "mount" > (eliminates variables that is). If I mount it, it first looks ok. Then I > write a file on it. Still looks ok. Then I call "sync". That finally locks > it up with the 2.6.32 kernel, not on 2.6.31. For the .32, it just sits > there, after probably twenty seconds, it times out, complains that it can't > write, then dies away. Works just nicely with the .31 kernel. > Perhaps both cases are related, and if you waited after those 5 minutes of resets, your pen would work fine... Have you checked your /var/log/messages after insertion of pen? My automount is under XFCE, not Gnome... ;) Josep > Thus, at this time, I guess I would need to know more about how a write > reaches the ehci module, and how the configuration from there works. > > Sorry, but this isn't quite as simple as I thought. > > Thanks, > Thomas -- -- Salutacions...Josep -- -- 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
Hi Josep, Have you tried to wait for 5 minutes? It could also be related to it what happens to my kernel 3.11.0-rc4 (and rc3) and USB I plug the drive. Only after 5 minutes of high-speed of USb bus, it mounts. No, currently I don't even depend on gnome mounting it. I don't run a desktop. I just mount it manually in the single user mode with "mount" (eliminates variables that is). If I mount it, it first looks ok. Then I write a file on it. Still looks ok. Then I call "sync". That finally locks it up with the 2.6.32 kernel, not on 2.6.31. For the .32, it just sits there, after probably twenty seconds, it times out, complains that it can't write, then dies away. Works just nicely with the .31 kernel. Thus, at this time, I guess I would need to know more about how a write reaches the ehci module, and how the configuration from there works. Sorry, but this isn't quite as simple as I thought. Thanks, Thomas -- 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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
On 10.08.2013 14:04, Alan Stern wrote: On Sat, 10 Aug 2013, Thomas Richter wrote: What about other usb modules? I would probably need a short recap on through which modules the user data flows before the write is triggered, and which modules are involved in the configuration of the NEC ehci host adapter. Start with just the ones you have identified. If that doesn't fix the problem then we can look further. Sorry, need to look further. I replaced ehci-pci from 2.6.31.14, and yenta_socket as well. No changes were necessary. Also replaced ehci-hcd, but that required two minor changes because in 2.6.32, apparently, one hardware related structure was pulled out of the ehci structure. Still did not make any difference, still locks up. What's the next module up in the call chain I should be looking at? Greetings, Thomas -- 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 V13 14/14] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor
* Raghavendra K T [2013-08-09 19:52:02]:
resending because x86_cpu_to_apicid is defined only for SMP systems.
so fold back kvm_kick_vcpu function into CONFIG_PARAVIRT_SPINLOCK that
depends on SMP. (this was taken out to for pv-flushtlb usage)
---8<---
>From 10e92f7911a8aed5b8574f53607ffc5d094d4de1 Mon Sep 17 00:00:00 2001
From: Srivatsa Vaddagiri
Date: Tue, 6 Aug 2013 14:55:41 +0530
Subject: [PATCH V13 14/14] kvm : Paravirtual ticketlocks support for linux
guests running on KVM hypervisor
During smp_boot_cpus paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PV_UNHALT) to support pv-ticketlocks. If so,
support for pv-ticketlocks is registered via pv_lock_ops.
Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
Signed-off-by: Srivatsa Vaddagiri
Signed-off-by: Suzuki Poulose
[Raghu: check_zero race fix, enum for kvm_contention_stat, jumplabel related
changes,
addition of safe_halt for irq enabled case, bailout spinning in nmi case(Gleb)]
Signed-off-by: Raghavendra K T
Acked-by: Gleb Natapov
Acked-by: Ingo Molnar
---
arch/x86/include/asm/kvm_para.h | 14 ++-
arch/x86/kernel/kvm.c | 262
2 files changed, 274 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 695399f..427afcb 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -118,10 +118,20 @@ void kvm_async_pf_task_wait(u32 token);
void kvm_async_pf_task_wake(u32 token);
u32 kvm_read_and_reset_pf_reason(void);
extern void kvm_disable_steal_time(void);
-#else
-#define kvm_guest_init() do { } while (0)
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+void __init kvm_spinlock_init(void);
+#else /* !CONFIG_PARAVIRT_SPINLOCKS */
+static inline void kvm_spinlock_init(void)
+{
+}
+#endif /* CONFIG_PARAVIRT_SPINLOCKS */
+
+#else /* CONFIG_KVM_GUEST */
+#define kvm_guest_init() do {} while (0)
#define kvm_async_pf_task_wait(T) do {} while(0)
#define kvm_async_pf_task_wake(T) do {} while(0)
+
static inline u32 kvm_read_and_reset_pf_reason(void)
{
return 0;
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index a96d32c..d442471 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -419,6 +420,7 @@ static void __init kvm_smp_prepare_boot_cpu(void)
WARN_ON(kvm_register_clock("primary cpu clock"));
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
+ kvm_spinlock_init();
}
static void kvm_guest_cpu_online(void *dummy)
@@ -523,3 +525,263 @@ static __init int activate_jump_labels(void)
return 0;
}
arch_initcall(activate_jump_labels);
+
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+
+/* Kick a cpu by its apicid. Used to wake up a halted vcpu */
+void kvm_kick_cpu(int cpu)
+{
+ int apicid;
+ unsigned long flags = 0;
+
+ apicid = per_cpu(x86_cpu_to_apicid, cpu);
+ kvm_hypercall2(KVM_HC_KICK_CPU, flags, apicid);
+}
+
+enum kvm_contention_stat {
+ TAKEN_SLOW,
+ TAKEN_SLOW_PICKUP,
+ RELEASED_SLOW,
+ RELEASED_SLOW_KICKED,
+ NR_CONTENTION_STATS
+};
+
+#ifdef CONFIG_KVM_DEBUG_FS
+#define HISTO_BUCKETS 30
+
+static struct kvm_spinlock_stats
+{
+ u32 contention_stats[NR_CONTENTION_STATS];
+ u32 histo_spin_blocked[HISTO_BUCKETS+1];
+ u64 time_blocked;
+} spinlock_stats;
+
+static u8 zero_stats;
+
+static inline void check_zero(void)
+{
+ u8 ret;
+ u8 old;
+
+ old = ACCESS_ONCE(zero_stats);
+ if (unlikely(old)) {
+ ret = cmpxchg(_stats, old, 0);
+ /* This ensures only one fellow resets the stat */
+ if (ret == old)
+ memset(_stats, 0, sizeof(spinlock_stats));
+ }
+}
+
+static inline void add_stats(enum kvm_contention_stat var, u32 val)
+{
+ check_zero();
+ spinlock_stats.contention_stats[var] += val;
+}
+
+
+static inline u64 spin_time_start(void)
+{
+ return sched_clock();
+}
+
+static void __spin_time_accum(u64 delta, u32 *array)
+{
+ unsigned index;
+
+ index = ilog2(delta);
+ check_zero();
+
+ if (index < HISTO_BUCKETS)
+ array[index]++;
+ else
+ array[HISTO_BUCKETS]++;
+}
+
+static inline void spin_time_accum_blocked(u64 start)
+{
+ u32 delta;
+
+ delta = sched_clock() - start;
+ __spin_time_accum(delta, spinlock_stats.histo_spin_blocked);
+ spinlock_stats.time_blocked += delta;
+}
+
+static struct dentry *d_spin_debug;
+static struct dentry *d_kvm_debug;
+
+struct dentry *kvm_init_debugfs(void)
+{
+ d_kvm_debug = debugfs_create_dir("kvm", NULL);
+ if (!d_kvm_debug)
+ printk(KERN_WARNING "Could not create 'kvm' debugfs
directory\n");
+
+ return d_kvm_debug;
+}
+
+static int __init kvm_spinlock_debugfs(void)
+{
+ struct
[PATCH v2] mm/hotplug: Verify hotplug memory range
add_memory() and remove_memory() can only handle a memory range aligned
with section. There are problems when an unaligned range is added and
then deleted as follows:
- add_memory() with an unaligned range succeeds, but __add_pages()
called from add_memory() adds a whole section of pages even though
a given memory range is less than the section size.
- remove_memory() to the added unaligned range hits BUG_ON() in
__remove_pages().
This patch changes add_memory() and remove_memory() to check if a given
memory range is aligned with section at the beginning. As the result,
add_memory() fails with -EINVAL when a given range is unaligned, and
does not add such memory range. This prevents remove_memory() to be
called with an unaligned range as well. Note that remove_memory() has
to use BUG_ON() since this function cannot fail.
Signed-off-by: Toshi Kani
Acked-by: KOSAKI Motohiro
Reviewed-by: Tang Chen
---
v2: Updated the error message.
---
mm/memory_hotplug.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca1dd3a..3bb1f39 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1069,6 +1069,22 @@ out:
return ret;
}
+static int check_hotplug_memory_range(u64 start, u64 size)
+{
+ u64 start_pfn = start >> PAGE_SHIFT;
+ u64 nr_pages = size >> PAGE_SHIFT;
+
+ /* Memory range must be aligned with section */
+ if ((start_pfn & ~PAGE_SECTION_MASK) ||
+ (nr_pages % PAGES_PER_SECTION) || (!nr_pages)) {
+ pr_err("Section-unaligned hotplug range: start 0x%llx, size
0x%llx\n",
+ start, size);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */
int __ref add_memory(int nid, u64 start, u64 size)
{
@@ -1078,6 +1094,10 @@ int __ref add_memory(int nid, u64 start, u64 size)
struct resource *res;
int ret;
+ ret = check_hotplug_memory_range(start, size);
+ if (ret)
+ return ret;
+
lock_memory_hotplug();
res = register_memory_resource(start, size);
@@ -1786,6 +1806,8 @@ void __ref remove_memory(int nid, u64 start, u64 size)
{
int ret;
+ BUG_ON(check_hotplug_memory_range(start, size));
+
lock_memory_hotplug();
/*
--
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] olpc-ec: initialise earlier
Being a low-level component, various drivers (e.g. olpc-battery) assume that
it is ok to communicate with the OLPC Embedded Controller during probe.
Therefore the OLPC EC driver must be initialised before other drivers try to
use it. This was the case until it was recently moved out of arch/x86 and
restructured.
Use arch_initcall so that olpc-ec is readied earlier, matching the
previous behaviour. Fixes various drivers such as olpc-battery and
olpc-xo1-sci.
Signed-off-by: Daniel Drake
---
drivers/platform/olpc/olpc-ec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 0f9f859..f911952 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -330,7 +330,7 @@ static int __init olpc_ec_init_module(void)
return platform_driver_register(_ec_plat_driver);
}
-module_init(olpc_ec_init_module);
+arch_initcall(olpc_ec_init_module);
MODULE_AUTHOR("Andres Salomon ");
MODULE_LICENSE("GPL");
--
1.8.3.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: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
Right... I mentioned the need to move thread count into percpu and the other
restructuring... all of that seems essential for this not to suck.
Linus Torvalds wrote:
>On Sat, Aug 10, 2013 at 10:18 AM, H. Peter Anvin wrote:
>>
>> We could then play a really ugly stunt by marking NEED_RESCHED by
>adding
>> 0x7fff to the counter. Then the whole sequence becomes something
>like:
>>
>> subl $1,%fs:preempt_count
>> jno 1f
>> call __naked_preempt_schedule /* Or a trap */
>
>This is indeed one of the few cases where we probably *could* use
>trapv or something like that in theory, but those instructions tend to
>be slow enough that even if you don't take the trap, you'd be better
>off just testing by hand.
>
>However, it's worse than you think. Preempt count is per-thread, not
>per-cpu. So to access preempt-count, we currently have to look up
>thread_info (which is per-cpu or stack-based).
>
>I'd *like* to make preempt-count be per-cpu, and then copy it at
>thread switch time, and it's been discussed. But as things are now,
>preemption enable is quite expensive, and looks something like
>
>movq %gs:kernel_stack,%rdx #, pfo_ret__
>subl$1, -8124(%rdx) #, ti_22->preempt_count
>movq %gs:kernel_stack,%rdx #, pfo_ret__
>movq-8136(%rdx), %rdx # MEM[(const long unsigned int
>*)ti_27 + 16B], D.
>andl$8, %edx#, D.34545
>jne .L139 #,
>
>and that's actually the *good* case (ie not counting any extra costs
>of turning leaf functions into non-leaf ones).
>
>That "kernel_stack" thing is actually getting the thread_info pointer,
>and it doesn't get cached because gcc thinks the preempt_count value
>might alias. Sad, sad, sad. We actually used to do better back when we
>used actual tricks with the stack registers and used a const inline
>asm to let gcc know it could re-use the value etc.
>
>It would be *lovely* if we
> (a) made preempt-count per-cpu and just copied it at thread-switch
> (b) made the NEED_RESCHED bit be part of preempt-count (rather than
>thread flags) and just made it the high bit
>
>adn then maybe we could just do
>
>subl$1, %fs:preempt_count
>js .L139
>
>with the actual schedule call being done as an
>
>asm volatile("call user_schedule": : :"memory");
>
>that Andi introduced that doesn't pollute the register space. Note
>that you still want the *test* to be done in C code, because together
>with "unlikely()" you'd likely do pretty close to optimal code
>generation, and hiding the decrement and test and conditional jump in
>asm you wouldn't get the proper instruction scheduling and branch
>following that gcc does.
>
>I dunno. It looks like a fair amount of effort. But as things are now,
>the code generation difference between PREEMPT_NONE and PREEMPT is
>actually fairly noticeable. And PREEMPT_VOLUNTARY - which is supposed
>to be almost as cheap as PREEMPT_NONE - has lots of bad cases too, as
>Andi noticed.
>
> Linus
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block
+ Grant
On Thu, Aug 1, 2013 at 5:10 PM, Kumar Gala wrote:
>> On Jul 29, 2013, at 4:40 PM, Stephen Boyd wrote:
>>> On 07/29, Kumar Gala wrote:
> diff --git a/Documentation/devicetree/bindings/arm/msm/tcsr-mutex.txt
> b/Documentation/devicetree/bindings/arm/msm/tcsr-mutex.txt
> new file mode 100644
> index 000..ddd6889
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/tcsr-mutex.txt
>>>
>>> Maybe this should go under a new hwspinlock directory?
>>
>> Will look for Ohad to comment on this.
>>
>>>
> @@ -0,0 +1,20 @@
> +Qualcomm MSM Hardware Mutex Block:
> +
> +The hardware block provides mutexes utilized between different processors
> +on the SoC as part of the communication protocol used by these
> processors.
> +
> +Required properties:
> +- compatible: should be "qcom,tcsr-mutex"
> +- reg: Should contain registers location and length of mutex registers
> +- reg-names:
> + "mutex-base" - string to identify mutex registers
> +- qcom,num-locks: the number of locks/mutexes supported
> +
> +Example:
> +
> + qcom,tcsr-mutex@fd484000 {
>>>
>>> Maybe it should be hw-mutex@fd484000?
>>
>> again, will look for Ohad to make some comment on this.
>>
> + compatible = "qcom,tcsr-mutex";
> + reg = <0xfd484000 0x1000>;
> + reg-names = "mutex-base";
> + qcom,num-locks = <32>;
> + };
>
> Ohad, ping.
I'd prefer a DT maintainer to take a look at your two open questions
above, especially if I'm to merge a new file into the devicetree
Documentation folder.
Grant, any chance you have a moment to take a look?
Otherwise, Stephen - do we have your Ack here? I was happy to see your
review but not sure what's the latest status.
Thanks,
Ohad.
--
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: [HANG] Trouble with NEC-based USB adapter in PCMCIA slot on E7110
On 10 August 2013 14:04, Alan Stern wrote: > On Sat, 10 Aug 2013, Thomas Richter wrote: > >> Which modules are relevant for handling the communication with the >> device, and where would you suggest to start looking? I assume >> yenta_socket is one thing for the cartbus adapter, then we have ehci_hcd >> and ehci_pci. Do I assume correctly that we can rule out the ohci_hcd >> module since that is not involved? > > That's right. > >> What about other usb modules? I would >> probably need a short recap on through which modules the user data flows >> before the write is triggered, and which modules are involved in the >> configuration of the NEC ehci host adapter. > > Start with just the ones you have identified. If that doesn't fix the > problem then we can look further. > Hello, Have you tried to wait for 5 minutes? It could also be related to it what happens to my kernel 3.11.0-rc4 (and rc3) and USB I plug the drive. Only after 5 minutes of high-speed of USb bus, it mounts. Aug 10 20:56:09 minijep kernel: [ 234.401608] usb 1-3: USB disconnect, device number 3 Aug 10 20:56:43 minijep kernel: [ 268.790914] usb 3-1.2: new high-speed USB device number 6 using ehci-pci Aug 10 20:56:43 minijep kernel: [ 268.886687] usb 3-1.2: New USB device found, idVendor=090c, idProduct=1000 Aug 10 20:56:43 minijep kernel: [ 268.886695] usb 3-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 10 20:56:43 minijep kernel: [ 268.886699] usb 3-1.2: Product: DISK Pro Aug 10 20:56:43 minijep kernel: [ 268.886702] usb 3-1.2: Manufacturer: USB Aug 10 20:56:43 minijep kernel: [ 268.886705] usb 3-1.2: SerialNumber: AA0401278773 Aug 10 20:56:43 minijep mtp-probe: checking bus 3, device 6: "/sys/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2" Aug 10 20:56:43 minijep kernel: [ 268.887447] usb-storage 3-1.2:1.0: USB Mass Storage device detected Aug 10 20:56:43 minijep kernel: [ 268.887714] scsi9 : usb-storage 3-1.2:1.0 Aug 10 20:56:43 minijep mtp-probe: bus: 3, device: 6 was not an MTP device Aug 10 20:56:44 minijep kernel: [ 269.889527] scsi 9:0:0:0: Direct-Access USB DISK Pro 1100 PQ: 0 ANSI: 0 CCS Aug 10 20:56:44 minijep kernel: [ 269.890025] sd 9:0:0:0: Attached scsi generic sg3 type 0 Aug 10 20:56:44 minijep kernel: [ 269.892356] sd 9:0:0:0: [sdc] 3963904 512-byte logical blocks: (2.02 GB/1.88 GiB) Aug 10 20:56:44 minijep kernel: [ 269.893461] sd 9:0:0:0: [sdc] Write Protect is off Aug 10 20:57:14 minijep kernel: [ 300.109604] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 20:57:45 minijep kernel: [ 331.207924] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 20:58:16 minijep kernel: [ 362.210362] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 20:58:47 minijep kernel: [ 393.212774] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 20:59:18 minijep kernel: [ 424.279257] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 20:59:49 minijep kernel: [ 455.345574] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 21:00:20 minijep kernel: [ 486.347994] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 21:00:51 minijep kernel: [ 517.350252] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 21:00:52 minijep kernel: [ 517.494528] sdc: sdc1 Aug 10 21:01:22 minijep kernel: [ 548.352623] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 21:01:53 minijep kernel: [ 579.355037] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci Aug 10 21:02:24 minijep kernel: [ 610.485609] usb 3-1.2: reset high-speed USB device number 6 using ehci-pci > Alan Stern > > -- > 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/ -- -- Salutacions...Josep -- -- 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:net:hamradio: Removing Depricated IRQF_DISABLED
On Sunday 11 August 2013 12:19 AM, walter harms wrote:
Hello Kumar,
i will try to resolve the riddle ...
doing something like fn(a,b,c,0) is a bad habit.
0 is called a "magic number" because noone reading the code has an idea
why it is there. Using the name IRQF_TRIGGER_NONE good.
Having a named bit like IRQ_TRIGGER|IRQ_NMI is most times also a good idea
because it correspond (most times) to the naming of the bits in the data sheet.
The problems starts when this hits reality since nothing is clearly black or
white.
In this case when you remove IRQF_DISABLED disables "bit" something should be
left.
a|b|IRQF_DISABLED -> a|b (that is the easy part)
but
IRQF_DISABLED -> IRQF_TRIGGER_NONE
Otherwise you would be left with "0". That is a magic number (see above).
So this is to be replaced by a placeholder called IRQF_TRIGGER_NONE.
hope that really helps and that i have understood the discussion.
re,
wh
Thanks for the clarification. I'll be following this.
Regards
Kumar Gaurav
Am 10.08.2013 20:15, schrieb Kumar Gaurav:
On Saturday 10 August 2013 10:54 PM, Julia Lawall wrote:
On Sat, 10 Aug 2013, Kumar Gaurav wrote:
On Saturday 10 August 2013 10:17 PM, Julia Lawall wrote:
If it is in a | with something else, I think you can just remove it.
julia
On Sat, 10 Aug 2013, Kumar Gaurav wrote:
Removed IRQF_DISABLED as it's deprecated and should be removed
Signed-off-by: Kumar Gaurav
---
drivers/net/hamradio/baycom_ser_fdx.c |2 +-
drivers/net/hamradio/baycom_ser_hdx.c |2 +-
drivers/net/hamradio/scc.c|2 +-
drivers/net/hamradio/yam.c|2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/hamradio/baycom_ser_fdx.c
b/drivers/net/hamradio/baycom_ser_fdx.c
index a974727..c114009 100644
--- a/drivers/net/hamradio/baycom_ser_fdx.c
+++ b/drivers/net/hamradio/baycom_ser_fdx.c
@@ -445,7 +445,7 @@ static int ser12_open(struct net_device *dev)
outb(0, FCR(dev->base_addr)); /* disable FIFOs */
outb(0x0d, MCR(dev->base_addr));
outb(0, IER(dev->base_addr));
-if (request_irq(dev->irq, ser12_interrupt, IRQF_DISABLED |
IRQF_SHARED,
+if (request_irq(dev->irq, ser12_interrupt, IRQF_TRIGGER_NONE |
IRQF_SHARED,
"baycom_ser_fdx", dev)) {
release_region(dev->base_addr, SER12_EXTENT);
return -EBUSY;
diff --git a/drivers/net/hamradio/baycom_ser_hdx.c
b/drivers/net/hamradio/baycom_ser_hdx.c
index e349d86..d91c1fd 100644
--- a/drivers/net/hamradio/baycom_ser_hdx.c
+++ b/drivers/net/hamradio/baycom_ser_hdx.c
@@ -490,7 +490,7 @@ static int ser12_open(struct net_device *dev)
outb(0, FCR(dev->base_addr)); /* disable FIFOs */
outb(0x0d, MCR(dev->base_addr));
outb(0, IER(dev->base_addr));
-if (request_irq(dev->irq, ser12_interrupt, IRQF_DISABLED |
IRQF_SHARED,
+if (request_irq(dev->irq, ser12_interrupt, IRQF_TRIGGER_NONE |
IRQF_SHARED,
"baycom_ser12", dev)) {
release_region(dev->base_addr, SER12_EXTENT);
return -EBUSY;
diff --git a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c
index bc1d521..4bc6ee8 100644
--- a/drivers/net/hamradio/scc.c
+++ b/drivers/net/hamradio/scc.c
@@ -1734,7 +1734,7 @@ static int scc_net_ioctl(struct net_device *dev,
struct ifreq *ifr, int cmd)
if (!Ivec[hwcfg.irq].used && hwcfg.irq)
{
if (request_irq(hwcfg.irq, scc_isr,
-IRQF_DISABLED, "AX.25 SCC",
+0, "AX.25 SCC",
(void *)(long) hwcfg.irq))
printk(KERN_WARNING "z8530drv:
warning, cannot get IRQ %d\n", hwcfg.irq);
else
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 0721e72..f947887 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -888,7 +888,7 @@ static int yam_open(struct net_device *dev)
goto out_release_base;
}
outb(0, IER(dev->base_addr));
-if (request_irq(dev->irq, yam_interrupt, IRQF_DISABLED |
IRQF_SHARED,
dev->name, dev)) {
+if (request_irq(dev->irq, yam_interrupt, IRQF_TRIGGER_NONE |
IRQF_SHARED, dev->name, dev)) {
printk(KERN_ERR "%s: irq %d busy\n", dev->name, dev->irq);
ret = -EBUSY;
goto out_release_base;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe
kernel-janitors"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Yes i was suggested for using IRQF_TRIGGER_NONE too so used this.
Please tell
me if this makes any difference or issue?
I think that the suggestion was to use IRQF_TRIGGER_NONE only when
removing IRQF_DISABLED would leave nothing left.
- IRQF_DISABLED | e
+ e
otherwise,
- IRQF_DISABLED
+ 0
julia
Sorry to prompt back but i'm confused. if removing IRQF_DISABLED leaves
nothing then should i use 0 or
Re: [PATCH] drivers:net:hamradio: Removing Depricated IRQF_DISABLED
Hello Kumar,
i will try to resolve the riddle ...
doing something like fn(a,b,c,0) is a bad habit.
0 is called a "magic number" because noone reading the code has an idea
why it is there. Using the name IRQF_TRIGGER_NONE good.
Having a named bit like IRQ_TRIGGER|IRQ_NMI is most times also a good idea
because it correspond (most times) to the naming of the bits in the data sheet.
The problems starts when this hits reality since nothing is clearly black or
white.
In this case when you remove IRQF_DISABLED disables "bit" something should be
left.
a|b|IRQF_DISABLED -> a|b (that is the easy part)
but
IRQF_DISABLED -> IRQF_TRIGGER_NONE
Otherwise you would be left with "0". That is a magic number (see above).
So this is to be replaced by a placeholder called IRQF_TRIGGER_NONE.
hope that really helps and that i have understood the discussion.
re,
wh
Am 10.08.2013 20:15, schrieb Kumar Gaurav:
> On Saturday 10 August 2013 10:54 PM, Julia Lawall wrote:
>> On Sat, 10 Aug 2013, Kumar Gaurav wrote:
>>
>>> On Saturday 10 August 2013 10:17 PM, Julia Lawall wrote:
If it is in a | with something else, I think you can just remove it.
julia
On Sat, 10 Aug 2013, Kumar Gaurav wrote:
> Removed IRQF_DISABLED as it's deprecated and should be removed
>
> Signed-off-by: Kumar Gaurav
> ---
>drivers/net/hamradio/baycom_ser_fdx.c |2 +-
>drivers/net/hamradio/baycom_ser_hdx.c |2 +-
>drivers/net/hamradio/scc.c|2 +-
>drivers/net/hamradio/yam.c|2 +-
>4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/hamradio/baycom_ser_fdx.c
> b/drivers/net/hamradio/baycom_ser_fdx.c
> index a974727..c114009 100644
> --- a/drivers/net/hamradio/baycom_ser_fdx.c
> +++ b/drivers/net/hamradio/baycom_ser_fdx.c
> @@ -445,7 +445,7 @@ static int ser12_open(struct net_device *dev)
>outb(0, FCR(dev->base_addr)); /* disable FIFOs */
>outb(0x0d, MCR(dev->base_addr));
>outb(0, IER(dev->base_addr));
> -if (request_irq(dev->irq, ser12_interrupt, IRQF_DISABLED |
> IRQF_SHARED,
> +if (request_irq(dev->irq, ser12_interrupt, IRQF_TRIGGER_NONE |
> IRQF_SHARED,
>"baycom_ser_fdx", dev)) {
>release_region(dev->base_addr, SER12_EXTENT);
>return -EBUSY;
> diff --git a/drivers/net/hamradio/baycom_ser_hdx.c
> b/drivers/net/hamradio/baycom_ser_hdx.c
> index e349d86..d91c1fd 100644
> --- a/drivers/net/hamradio/baycom_ser_hdx.c
> +++ b/drivers/net/hamradio/baycom_ser_hdx.c
> @@ -490,7 +490,7 @@ static int ser12_open(struct net_device *dev)
>outb(0, FCR(dev->base_addr)); /* disable FIFOs */
>outb(0x0d, MCR(dev->base_addr));
>outb(0, IER(dev->base_addr));
> -if (request_irq(dev->irq, ser12_interrupt, IRQF_DISABLED |
> IRQF_SHARED,
> +if (request_irq(dev->irq, ser12_interrupt, IRQF_TRIGGER_NONE |
> IRQF_SHARED,
>"baycom_ser12", dev)) {
>release_region(dev->base_addr, SER12_EXTENT);
>return -EBUSY;
> diff --git a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c
> index bc1d521..4bc6ee8 100644
> --- a/drivers/net/hamradio/scc.c
> +++ b/drivers/net/hamradio/scc.c
> @@ -1734,7 +1734,7 @@ static int scc_net_ioctl(struct net_device *dev,
> struct ifreq *ifr, int cmd)
>if (!Ivec[hwcfg.irq].used && hwcfg.irq)
>{
>if (request_irq(hwcfg.irq, scc_isr,
> -IRQF_DISABLED, "AX.25 SCC",
> +0, "AX.25 SCC",
>(void *)(long) hwcfg.irq))
>printk(KERN_WARNING "z8530drv:
> warning, cannot get IRQ %d\n", hwcfg.irq);
>else
> diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
> index 0721e72..f947887 100644
> --- a/drivers/net/hamradio/yam.c
> +++ b/drivers/net/hamradio/yam.c
> @@ -888,7 +888,7 @@ static int yam_open(struct net_device *dev)
>goto out_release_base;
>}
>outb(0, IER(dev->base_addr));
> -if (request_irq(dev->irq, yam_interrupt, IRQF_DISABLED |
> IRQF_SHARED,
> dev->name, dev)) {
> +if (request_irq(dev->irq, yam_interrupt, IRQF_TRIGGER_NONE |
> IRQF_SHARED, dev->name, dev)) {
>printk(KERN_ERR "%s: irq %d busy\n", dev->name, dev->irq);
>ret = -EBUSY;
>goto out_release_base;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> kernel-janitors"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>>> Yes i was suggested for using
Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY
On Sat, Aug 10, 2013 at 10:18 AM, H. Peter Anvin wrote:
>
> We could then play a really ugly stunt by marking NEED_RESCHED by adding
> 0x7fff to the counter. Then the whole sequence becomes something like:
>
> subl $1,%fs:preempt_count
> jno 1f
> call __naked_preempt_schedule /* Or a trap */
This is indeed one of the few cases where we probably *could* use
trapv or something like that in theory, but those instructions tend to
be slow enough that even if you don't take the trap, you'd be better
off just testing by hand.
However, it's worse than you think. Preempt count is per-thread, not
per-cpu. So to access preempt-count, we currently have to look up
thread_info (which is per-cpu or stack-based).
I'd *like* to make preempt-count be per-cpu, and then copy it at
thread switch time, and it's been discussed. But as things are now,
preemption enable is quite expensive, and looks something like
movq %gs:kernel_stack,%rdx #, pfo_ret__
subl$1, -8124(%rdx) #, ti_22->preempt_count
movq %gs:kernel_stack,%rdx #, pfo_ret__
movq-8136(%rdx), %rdx # MEM[(const long unsigned int
*)ti_27 + 16B], D.
andl$8, %edx#, D.34545
jne .L139 #,
and that's actually the *good* case (ie not counting any extra costs
of turning leaf functions into non-leaf ones).
That "kernel_stack" thing is actually getting the thread_info pointer,
and it doesn't get cached because gcc thinks the preempt_count value
might alias. Sad, sad, sad. We actually used to do better back when we
used actual tricks with the stack registers and used a const inline
asm to let gcc know it could re-use the value etc.
It would be *lovely* if we
(a) made preempt-count per-cpu and just copied it at thread-switch
(b) made the NEED_RESCHED bit be part of preempt-count (rather than
thread flags) and just made it the high bit
adn then maybe we could just do
subl$1, %fs:preempt_count
js .L139
with the actual schedule call being done as an
asm volatile("call user_schedule": : :"memory");
that Andi introduced that doesn't pollute the register space. Note
that you still want the *test* to be done in C code, because together
with "unlikely()" you'd likely do pretty close to optimal code
generation, and hiding the decrement and test and conditional jump in
asm you wouldn't get the proper instruction scheduling and branch
following that gcc does.
I dunno. It looks like a fair amount of effort. But as things are now,
the code generation difference between PREEMPT_NONE and PREEMPT is
actually fairly noticeable. And PREEMPT_VOLUNTARY - which is supposed
to be almost as cheap as PREEMPT_NONE - has lots of bad cases too, as
Andi noticed.
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/
