Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop
On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote: > On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleixner wrote: > > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote: > > > > > Attached, but heads up on this: when redirecting the output of lspci > > > -vvv to a text file as root I get > > > > > > pcilib: sysfs_read_vpd: read failed: Input/output error > > > > > > I can find bugs filed for various distros to this same effect, but > > > haven't tracked down any explanations. > > > > Weird, but the info looks complete. > > > > Can you please add 'pci=nomsi' to the 4.15 kernel command line and see > > whether that works? > > It does (emailing from that successful boot as we speak). I'm on a > clean 4.15-rc5 (as in no patches, etc.). > > This was also suggested way at the top of this thread by Dexuan Cui > for 4.15-rc3 (where this exchange started), and it worked back then > too. I missed that part of the conversation. Let me stare into the MSI code again. Thanks, tglx ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] android: binder: Prefer __func__ to using hardcoded function name
Coding style fixup
Signed-off-by: Elad Wexler
---
drivers/android/binder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index bccec9d..a66ad3d 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4631,7 +4631,7 @@ static int binder_mmap(struct file *filp, struct
vm_area_struct *vma)
return 0;
err_bad_arg:
- pr_err("binder_mmap: %d %lx-%lx %s failed %d\n",
+ pr_err("%s: %d %lx-%lx %s failed %d\n", __func__,
proc->pid, vma->vm_start, vma->vm_end, failure_string, ret);
return ret;
}
@@ -4641,7 +4641,7 @@ static int binder_open(struct inode *nodp, struct file
*filp)
struct binder_proc *proc;
struct binder_device *binder_dev;
- binder_debug(BINDER_DEBUG_OPEN_CLOSE, "binder_open: %d:%d\n",
+ binder_debug(BINDER_DEBUG_OPEN_CLOSE, "%s: %d:%d\n", __func__,
current->group_leader->pid, current->pid);
proc = kzalloc(sizeof(*proc), GFP_KERNEL);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop
All right, I tried to do some more digging around, in the hope of
getting as close to the source of the problem as I can.
I went back to the very first commit that went astray for me, 2db1f95
(which is the only one actually panicking), and tried to move from its
parent 90ad9e2 (that boots fine) to it gradually, altering the code in
small chunks.
I tried to ignore the stuff that clearly shouldn't make a difference,
such as definitions. So in the end I get defined-but-unused-function
errors in my compilations, but I'm ignoring those for now. Some
results:
(1) When I move from the good commit 90ad9e2 according to the attached
bad-diff (which moves partly towards 2db1f95), I get a panic.
(2) On the other hand, when I further change this last panicking
commit by simply doing
removed activate / deactivate from x86_vector_domain_ops
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 7317ba5a..063594d 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -514,8 +514,6 @@ void x86_vector_debug_show(struct seq_file *m, struct
irq_domain *d,
static const struct irq_domain_ops x86_vector_domain_ops = {
.alloc = x86_vector_alloc_irqs,
.free = x86_vector_free_irqs,
- .activate = x86_vector_activate,
- .deactivate = x86_vector_deactivate,
#ifdef CONFIG_GENERIC_IRQ_DEBUGFS
.debug_show = x86_vector_debug_show,
#endif
all is well.
On Fri, Dec 29, 2017 at 09:07:45AM +0100, Thomas Gleixner wrote:
> On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleixner wrote:
> > > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > >
> > > > Attached, but heads up on this: when redirecting the output of lspci
> > > > -vvv to a text file as root I get
> > > >
> > > > pcilib: sysfs_read_vpd: read failed: Input/output error
> > > >
> > > > I can find bugs filed for various distros to this same effect, but
> > > > haven't tracked down any explanations.
> > >
> > > Weird, but the info looks complete.
> > >
> > > Can you please add 'pci=nomsi' to the 4.15 kernel command line and see
> > > whether that works?
> >
> > It does (emailing from that successful boot as we speak). I'm on a
> > clean 4.15-rc5 (as in no patches, etc.).
> >
> > This was also suggested way at the top of this thread by Dexuan Cui
> > for 4.15-rc3 (where this exchange started), and it worked back then
> > too.
>
> I missed that part of the conversation. Let me stare into the MSI code
> again.
>
> Thanks,
>
> tglx
diff --git a/arch/x86/include/asm/irq_vectors.h
b/arch/x86/include/asm/irq_vectors.h
index aaf8d28..1e9bd28 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -101,12 +101,8 @@
#define POSTED_INTR_NESTED_VECTOR 0xf0
#endif
-/*
- * Local APIC timer IRQ vector is on a different priority level,
- * to work around the 'lost local interrupt if more than 2 IRQ
- * sources per level' errata.
- */
-#define LOCAL_TIMER_VECTOR 0xef
+#define MANAGED_IRQ_SHUTDOWN_VECTOR0xef
+#define LOCAL_TIMER_VECTOR 0xee
#define NR_VECTORS 256
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index f08d44f..7317ba5a 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -32,7 +32,8 @@ struct apic_chip_data {
unsigned intprev_cpu;
unsigned intirq;
struct hlist_node clist;
- u8 move_in_progress : 1;
+ unsigned intmove_in_progress: 1,
+ is_managed : 1;
};
struct irq_domain *x86_vector_domain;
@@ -152,6 +153,28 @@ static void apic_update_vector(struct irq_data *irqd,
unsigned int newvec,
per_cpu(vector_irq, newcpu)[newvec] = desc;
}
+static void vector_assign_managed_shutdown(struct irq_data *irqd)
+{
+ unsigned int cpu = cpumask_first(cpu_online_mask);
+
+ apic_update_irq_cfg(irqd, MANAGED_IRQ_SHUTDOWN_VECTOR, cpu);
+}
+
+static int reserve_managed_vector(struct irq_data *irqd)
+{
+ const struct cpumask *affmsk = irq_data_get_affinity_mask(irqd);
+ struct apic_chip_data *apicd = apic_chip_data(irqd);
+ unsigned long flags;
+ int ret;
+
+ raw_spin_lock_irqsave(&vector_lock, flags);
+ apicd->is_managed = true;
+ ret = irq_matrix_reserve_managed(vector_matrix, affmsk);
+ raw_spin_unlock_irqrestore(&vector_lock, flags);
+ trace_vector_reserve_managed(irqd->irq, ret);
+ return ret;
+}
+
static int allocate_vector(struct irq_data *irqd, const struct cpumask *dest)
{
struct apic_chip_data *apicd = apic_chip_data(irqd);
@@ -211,9 +234,58 @@ static int assign_irq_v
Re: [PATCH 1/2] staging: iio: remove unnecessary parentheses
On Wed, 27 Dec 2017 18:47:18 -0800
Ji-Hun Kim wrote:
> Clean up checkpatch warning:
> CHECK: Unnecessary parentheses around 'st->devid != ID_AD7195'
>
> Signed-off-by: Ji-Hun Kim
I've personally never really cared about this particular one as
removing the brackets doesn't make the code easier to read.
However, it is worthwhile to suppress checkpatch warnings so
we can see the ones that matter.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index cadfb96..f015955 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -271,7 +271,7 @@ static int ad7192_setup(struct ad7192_state *st,
> if (pdata->sinc3_en)
> st->mode |= AD7192_MODE_SINC3;
>
> - if (pdata->refin2_en && (st->devid != ID_AD7195))
> + if (pdata->refin2_en && st->devid != ID_AD7195)
> st->conf |= AD7192_CONF_REFSEL;
>
> if (pdata->chop_en) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: iio: add spaces around '-' operator
On Thu, 28 Dec 2017 07:07:17 +0100 (CET) Julia Lawall wrote: > On Wed, 27 Dec 2017, Ji-Hun Kim wrote: > > > Clean up checkpatch warning: > > CHECK: spaces preferred around that '-' (ctx:VxV) > > > > Signed-off-by: Ji-Hun Kim > > --- > > drivers/staging/iio/adc/ad7192.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/iio/adc/ad7192.c > > b/drivers/staging/iio/adc/ad7192.c > > index f015955..c4eff71 100644 > > --- a/drivers/staging/iio/adc/ad7192.c > > +++ b/drivers/staging/iio/adc/ad7192.c > > @@ -340,7 +340,7 @@ ad7192_show_scale_available(struct device *dev, > > } > > > > static IIO_DEVICE_ATTR_NAMED(in_v_m_v_scale_available, > > -in_voltage-voltage_scale_available, > > +in_voltage - voltage_scale_available, > > I think this has been discussed at length before, and it is a hyphen not a > subtraction. IIO_DEVICE_ATTR_NAMED is a macro, as indicated by the > capital letters, and you have to look and see what the code expands into. Technically it is a subtraction, but the symbol rather than the c operator ;) It's indicating that this sysfs attribute is referring to any voltage channels minus other voltage channels (differential channels). Sometimes I wonder if we should leave this there for ever as a way of getting people to understand that they need to look really closely at what checkpatch is suggesting and not assume it is right. Jonathan > > julia > > > 0444, ad7192_show_scale_available, NULL, 0); > > > > static IIO_DEVICE_ATTR(in_voltage_scale_available, 0444, > > -- > > 2.10.1 (Apple Git-78) > > > > -- > > 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 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop
On Fri, Dec 29, 2017 at 06:49:15AM -0500, Alexandru Chirvasitu wrote:
> All right, I tried to do some more digging around, in the hope of
> getting as close to the source of the problem as I can.
>
> I went back to the very first commit that went astray for me, 2db1f95
> (which is the only one actually panicking), and tried to move from its
> parent 90ad9e2 (that boots fine) to it gradually, altering the code in
> small chunks.
>
> I tried to ignore the stuff that clearly shouldn't make a difference,
> such as definitions. So in the end I get defined-but-unused-function
> errors in my compilations, but I'm ignoring those for now. Some
> results:
>
> (1) When I move from the good commit 90ad9e2 according to the attached
> bad-diff (which moves partly towards 2db1f95), I get a panic.
>
> (2) On the other hand, when I further change this last panicking
> commit by simply doing
>
>
>
> removed activate / deactivate from x86_vector_domain_ops
>
> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> index 7317ba5a..063594d 100644
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -514,8 +514,6 @@ void x86_vector_debug_show(struct seq_file *m, struct
> irq_domain *d,
> static const struct irq_domain_ops x86_vector_domain_ops = {
> .alloc = x86_vector_alloc_irqs,
> .free = x86_vector_free_irqs,
> - .activate = x86_vector_activate,
> - .deactivate = x86_vector_deactivate,
> #ifdef CONFIG_GENERIC_IRQ_DEBUGFS
> .debug_show = x86_vector_debug_show,
> #endif
>
>
> all is well.
>
And sure enough, simply diffing
removed activate / deactivate from x86_vector_domain_ops
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 3f53572..e6cb55d 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -511,8 +511,6 @@ void x86_vector_debug_show(struct seq_file *m, struct
irq_domain *d,
static const struct irq_domain_ops x86_vector_domain_ops = {
.alloc = x86_vector_alloc_irqs,
.free = x86_vector_free_irqs,
- .activate = x86_vector_activate,
- .deactivate = x86_vector_deactivate,
#ifdef CONFIG_GENERIC_IRQ_DEBUGFS
.debug_show = x86_vector_debug_show,
#endif
directly against 2db1f95 fixes the issues (no freezes, lockups, or
panics).
>
>
>
> On Fri, Dec 29, 2017 at 09:07:45AM +0100, Thomas Gleixner wrote:
> > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > > On Fri, Dec 29, 2017 at 12:36:37AM +0100, Thomas Gleixner wrote:
> > > > On Thu, 28 Dec 2017, Alexandru Chirvasitu wrote:
> > > >
> > > > > Attached, but heads up on this: when redirecting the output of lspci
> > > > > -vvv to a text file as root I get
> > > > >
> > > > > pcilib: sysfs_read_vpd: read failed: Input/output error
> > > > >
> > > > > I can find bugs filed for various distros to this same effect, but
> > > > > haven't tracked down any explanations.
> > > >
> > > > Weird, but the info looks complete.
> > > >
> > > > Can you please add 'pci=nomsi' to the 4.15 kernel command line and see
> > > > whether that works?
> > >
> > > It does (emailing from that successful boot as we speak). I'm on a
> > > clean 4.15-rc5 (as in no patches, etc.).
> > >
> > > This was also suggested way at the top of this thread by Dexuan Cui
> > > for 4.15-rc3 (where this exchange started), and it worked back then
> > > too.
> >
> > I missed that part of the conversation. Let me stare into the MSI code
> > again.
> >
> > Thanks,
> >
> > tglx
> diff --git a/arch/x86/include/asm/irq_vectors.h
> b/arch/x86/include/asm/irq_vectors.h
> index aaf8d28..1e9bd28 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -101,12 +101,8 @@
> #define POSTED_INTR_NESTED_VECTOR0xf0
> #endif
>
> -/*
> - * Local APIC timer IRQ vector is on a different priority level,
> - * to work around the 'lost local interrupt if more than 2 IRQ
> - * sources per level' errata.
> - */
> -#define LOCAL_TIMER_VECTOR 0xef
> +#define MANAGED_IRQ_SHUTDOWN_VECTOR 0xef
> +#define LOCAL_TIMER_VECTOR 0xee
>
> #define NR_VECTORS256
>
> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> index f08d44f..7317ba5a 100644
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -32,7 +32,8 @@ struct apic_chip_data {
> unsigned intprev_cpu;
> unsigned intirq;
> struct hlist_node clist;
> - u8 move_in_progress : 1;
> + unsigned intmove_in_progress: 1,
>
[PATCH] staging: android: check for error from register_shrinker in ion_heap_init_shrinker
The function register_shrinker in ion_heap_init_shrinker may return an
error, check it out. Meanwhile, ion_heap_init_shrinker has to a return
value.
Signed-off-by: Xiongwei Song
---
drivers/staging/android/ion/ion.c | 8 ++--
drivers/staging/android/ion/ion.h | 2 +-
drivers/staging/android/ion/ion_heap.c | 5 +++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index bb2c4b07badd..57e0d8035b2e 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -529,6 +529,7 @@ void ion_device_add_heap(struct ion_heap *heap)
{
struct dentry *debug_file;
struct ion_device *dev = internal_dev;
+ int ret;
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -540,8 +541,11 @@ void ion_device_add_heap(struct ion_heap *heap)
if (heap->flags & ION_HEAP_FLAG_DEFER_FREE)
ion_heap_init_deferred_free(heap);
- if ((heap->flags & ION_HEAP_FLAG_DEFER_FREE) || heap->ops->shrink)
- ion_heap_init_shrinker(heap);
+ if ((heap->flags & ION_HEAP_FLAG_DEFER_FREE) || heap->ops->shrink) {
+ ret = ion_heap_init_shrinker(heap);
+ if (ret)
+ pr_err("%s: Failed to register shrinker\n", __func__);
+ }
heap->dev = dev;
down_write(&dev->lock);
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index c24c6e230654..a238f23c9116 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -230,7 +230,7 @@ int ion_alloc(size_t len,
* this function will be called to setup a shrinker to shrink the freelists
* and call the heap's shrink op.
*/
-void ion_heap_init_shrinker(struct ion_heap *heap);
+int ion_heap_init_shrinker(struct ion_heap *heap);
/**
* ion_heap_init_deferred_free -- initialize deferred free functionality
diff --git a/drivers/staging/android/ion/ion_heap.c
b/drivers/staging/android/ion/ion_heap.c
index 2af86a2d94fb..772dad65396e 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -297,11 +297,12 @@ static unsigned long ion_heap_shrink_scan(struct shrinker
*shrinker,
return freed;
}
-void ion_heap_init_shrinker(struct ion_heap *heap)
+int ion_heap_init_shrinker(struct ion_heap *heap)
{
heap->shrinker.count_objects = ion_heap_shrink_count;
heap->shrinker.scan_objects = ion_heap_shrink_scan;
heap->shrinker.seeks = DEFAULT_SEEKS;
heap->shrinker.batch = 0;
- register_shrinker(&heap->shrinker);
+
+ return register_shrinker(&heap->shrinker);
}
--
2.15.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop
On Fri, 29 Dec 2017, Alexandru Chirvasitu wrote:
> All right, I tried to do some more digging around, in the hope of
> getting as close to the source of the problem as I can.
>
> I went back to the very first commit that went astray for me, 2db1f95
> (which is the only one actually panicking), and tried to move from its
> parent 90ad9e2 (that boots fine) to it gradually, altering the code in
> small chunks.
>
> I tried to ignore the stuff that clearly shouldn't make a difference,
> such as definitions. So in the end I get defined-but-unused-function
> errors in my compilations, but I'm ignoring those for now. Some
> results:
>
> (1) When I move from the good commit 90ad9e2 according to the attached
> bad-diff (which moves partly towards 2db1f95), I get a panic.
>
> (2) On the other hand, when I further change this last panicking
> commit by simply doing
>
>
>
> removed activate / deactivate from x86_vector_domain_ops
>
> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> index 7317ba5a..063594d 100644
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -514,8 +514,6 @@ void x86_vector_debug_show(struct seq_file *m, struct
> irq_domain *d,
> static const struct irq_domain_ops x86_vector_domain_ops = {
> .alloc = x86_vector_alloc_irqs,
> .free = x86_vector_free_irqs,
> - .activate = x86_vector_activate,
> - .deactivate = x86_vector_deactivate,
> #ifdef CONFIG_GENERIC_IRQ_DEBUGFS
> .debug_show = x86_vector_debug_show,
> #endif
>
>
> all is well.
Nice detective work. Unfortunately that's not a real solution ...
Can you try the patch below on top of Linus tree, please?
Thanks,
tglx
8<-
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -339,6 +339,40 @@ int msi_domain_populate_irqs(struct irq_
return ret;
}
+/*
+ * Carefully check whether the device can use reservation mode. If
+ * reservation mode is enabled then the early activation will assign a
+ * dummy vector to the device. If the PCI/MSI device does not support
+ * masking of the entry then this can result in spurious interrupts when
+ * the device driver is not absolutely careful. But even then a malfunction
+ * of the hardware could result in a spurious interrupt on the dummy vector
+ * and render the device unusable. If the entry can be masked then the core
+ * logic will prevent the spurious interrupt and reservation mode can be
+ * used. For now reservation mode is restricted to PCI/MSI.
+ */
+static bool msi_check_reservation_mode(struct irq_domain *domain,
+ struct msi_domain_info *info,
+ struct device *dev)
+{
+ struct msi_desc *desc;
+
+ if (domain->bus_token != DOMAIN_BUS_PCI_MSI)
+ return false;
+
+ if (!(info->flags & MSI_FLAG_MUST_REACTIVATE))
+ return false;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_ignore_mask)
+ return false;
+
+ /*
+* Checking the first MSI descriptor is sufficient. MSIX supports
+* masking and MSI does so when the maskbit is set.
+*/
+ desc = first_msi_entry(dev);
+ return desc->msi_attrib.is_msix || desc->msi_attrib.maskbit;
+}
+
/**
* msi_domain_alloc_irqs - Allocate interrupts from a MSI interrupt domain
* @domain:The domain to allocate from
@@ -353,9 +387,11 @@ int msi_domain_alloc_irqs(struct irq_dom
{
struct msi_domain_info *info = domain->host_data;
struct msi_domain_ops *ops = info->ops;
- msi_alloc_info_t arg;
+ struct irq_data *irq_data;
struct msi_desc *desc;
+ msi_alloc_info_t arg;
int i, ret, virq;
+ bool can_reserve;
ret = msi_domain_prepare_irqs(domain, dev, nvec, &arg);
if (ret)
@@ -385,6 +421,8 @@ int msi_domain_alloc_irqs(struct irq_dom
if (ops->msi_finish)
ops->msi_finish(&arg, 0);
+ can_reserve = msi_check_reservation_mode(domain, info, dev);
+
for_each_msi_entry(desc, dev) {
virq = desc->irq;
if (desc->nvec_used == 1)
@@ -397,17 +435,28 @@ int msi_domain_alloc_irqs(struct irq_dom
* the MSI entries before the PCI layer enables MSI in the
* card. Otherwise the card latches a random msi message.
*/
- if (info->flags & MSI_FLAG_ACTIVATE_EARLY) {
- struct irq_data *irq_data;
+ if (!(info->flags & MSI_FLAG_ACTIVATE_EARLY))
+ continue;
+ irq_data = irq_domain_get_irq_data(domain, desc->irq);
+ if (!can_reserve)
+ irqd_clr_can_reserve(irq_data);
+ ret = irq_domain_activate_irq(i
Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop
On Fri, Dec 29, 2017 at 02:09:40PM +0100, Thomas Gleixner wrote:
> On Fri, 29 Dec 2017, Alexandru Chirvasitu wrote:
> > All right, I tried to do some more digging around, in the hope of
> > getting as close to the source of the problem as I can.
> >
> > I went back to the very first commit that went astray for me, 2db1f95
> > (which is the only one actually panicking), and tried to move from its
> > parent 90ad9e2 (that boots fine) to it gradually, altering the code in
> > small chunks.
> >
> > I tried to ignore the stuff that clearly shouldn't make a difference,
> > such as definitions. So in the end I get defined-but-unused-function
> > errors in my compilations, but I'm ignoring those for now. Some
> > results:
> >
> > (1) When I move from the good commit 90ad9e2 according to the attached
> > bad-diff (which moves partly towards 2db1f95), I get a panic.
> >
> > (2) On the other hand, when I further change this last panicking
> > commit by simply doing
> >
> >
> >
> > removed activate / deactivate from x86_vector_domain_ops
> >
> > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> > index 7317ba5a..063594d 100644
> > --- a/arch/x86/kernel/apic/vector.c
> > +++ b/arch/x86/kernel/apic/vector.c
> > @@ -514,8 +514,6 @@ void x86_vector_debug_show(struct seq_file *m, struct
> > irq_domain *d,
> > static const struct irq_domain_ops x86_vector_domain_ops = {
> > .alloc = x86_vector_alloc_irqs,
> > .free = x86_vector_free_irqs,
> > - .activate = x86_vector_activate,
> > - .deactivate = x86_vector_deactivate,
> > #ifdef CONFIG_GENERIC_IRQ_DEBUGFS
> > .debug_show = x86_vector_debug_show,
> > #endif
> >
> >
> > all is well.
>
> Nice detective work. Unfortunately that's not a real solution ...
>
Oh, of course. It was never intended as a solution, only as
information perhaps enabling someone who knows what they're doing
(unlike myself :) ) to find one.
> Can you try the patch below on top of Linus tree, please?
>
> Thanks,
>
Applied it to 464e1d5 4.15-rc5 just now. it appears to be
trouble-free: booted, logged me in fine, the works.
> tglx
>
> 8<-
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -339,6 +339,40 @@ int msi_domain_populate_irqs(struct irq_
> return ret;
> }
>
> +/*
> + * Carefully check whether the device can use reservation mode. If
> + * reservation mode is enabled then the early activation will assign a
> + * dummy vector to the device. If the PCI/MSI device does not support
> + * masking of the entry then this can result in spurious interrupts when
> + * the device driver is not absolutely careful. But even then a malfunction
> + * of the hardware could result in a spurious interrupt on the dummy vector
> + * and render the device unusable. If the entry can be masked then the core
> + * logic will prevent the spurious interrupt and reservation mode can be
> + * used. For now reservation mode is restricted to PCI/MSI.
> + */
> +static bool msi_check_reservation_mode(struct irq_domain *domain,
> +struct msi_domain_info *info,
> +struct device *dev)
> +{
> + struct msi_desc *desc;
> +
> + if (domain->bus_token != DOMAIN_BUS_PCI_MSI)
> + return false;
> +
> + if (!(info->flags & MSI_FLAG_MUST_REACTIVATE))
> + return false;
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI) && pci_msi_ignore_mask)
> + return false;
> +
> + /*
> + * Checking the first MSI descriptor is sufficient. MSIX supports
> + * masking and MSI does so when the maskbit is set.
> + */
> + desc = first_msi_entry(dev);
> + return desc->msi_attrib.is_msix || desc->msi_attrib.maskbit;
> +}
> +
> /**
> * msi_domain_alloc_irqs - Allocate interrupts from a MSI interrupt domain
> * @domain: The domain to allocate from
> @@ -353,9 +387,11 @@ int msi_domain_alloc_irqs(struct irq_dom
> {
> struct msi_domain_info *info = domain->host_data;
> struct msi_domain_ops *ops = info->ops;
> - msi_alloc_info_t arg;
> + struct irq_data *irq_data;
> struct msi_desc *desc;
> + msi_alloc_info_t arg;
> int i, ret, virq;
> + bool can_reserve;
>
> ret = msi_domain_prepare_irqs(domain, dev, nvec, &arg);
> if (ret)
> @@ -385,6 +421,8 @@ int msi_domain_alloc_irqs(struct irq_dom
> if (ops->msi_finish)
> ops->msi_finish(&arg, 0);
>
> + can_reserve = msi_check_reservation_mode(domain, info, dev);
> +
> for_each_msi_entry(desc, dev) {
> virq = desc->irq;
> if (desc->nvec_used == 1)
> @@ -397,17 +435,28 @@ int msi_domain_alloc_irqs(struct irq_dom
>* the MSI entries before the PCI layer enables MSI in the
>
Re: [PATCH 2/2] Staging: most: aim-sound: sound.c: removed unnecessary parentheses
On Fri, Dec 29, 2017 at 02:19:56AM +0300, Ozgur wrote: > I think this patch is not good, the code will not work. Please should > understand in && operator and () why used with C. hi, this patch should work, since it compiles and passes checkpatch. the reason why i removed the () is because of the && operator, it works without the need of having () around the statments, which makes the code simpler to read. have a nice day. -phil loctauxphili...@gmail.com https://philippeloctaux.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: most: convert macro to static function
This fixes checkpatch warning:
CHECK: Macro argument reuse 'buf' - possible side effects?
Signed-off-by: George Edward Bulmer
---
drivers/staging/most/net/net.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/most/net/net.c b/drivers/staging/most/net/net.c
index 33606584e50e..30d816b7e165 100644
--- a/drivers/staging/most/net/net.c
+++ b/drivers/staging/most/net/net.c
@@ -46,10 +46,12 @@
((len) > MEP_HDR_LEN && \
EXTRACT_BIT_SET(PMS_FIFONO, (buf)[3]) == PMS_FIFONO_MEP)
-#define PMS_IS_MAMAC(buf, len) \
- ((len) > MDP_HDR_LEN && \
-EXTRACT_BIT_SET(PMS_FIFONO, (buf)[3]) == PMS_FIFONO_MDP && \
-EXTRACT_BIT_SET(PMS_TELID, (buf)[14]) == PMS_TELID_UNSEGM_MAMAC)
+static inline bool pms_is_mamac(char *buf, u32 len)
+{
+ return (len > MDP_HDR_LEN &&
+ EXTRACT_BIT_SET(PMS_FIFONO, buf[3]) == PMS_FIFONO_MDP &&
+ EXTRACT_BIT_SET(PMS_TELID, buf[14]) == PMS_TELID_UNSEGM_MAMAC);
+}
struct net_dev_channel {
bool linked;
@@ -435,7 +437,7 @@ static int comp_rx_data(struct mbo *mbo)
dev = nd->dev;
if (nd->is_mamac) {
- if (!PMS_IS_MAMAC(buf, len)) {
+ if (!pms_is_mamac(buf, len)) {
ret = -EIO;
goto put_nd;
}
--
2.15.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: ATTENTION!!!
From: Loretta Robles Sent: Friday, December 29, 2017 1:01 PM To: Loretta Robles Subject: ATTENTION!!! You have been randomly selected for a donation. Contact soriz4...@gmail.com for claims. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: pi433 - fix ccheckpatch issue, updated include line.
Updated the include of compat.h to fix checkpatch error Signed-off-by: Derek Robson --- drivers/staging/pi433/pi433_if.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index 1d7c50c1ac23..0555c76cea49 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -48,7 +48,7 @@ #include #include #ifdef CONFIG_COMPAT -#include +#include #endif #include "pi433_if.h" -- 2.15.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
