[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200826112334.795343913@linutronix.de>
Date: Wed, 26 Aug 2020 13:17:10 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: LKML <linux-kernel@...r.kernel.org>
Cc: x86@...nel.org, Joerg Roedel <joro@...tes.org>,
iommu@...ts.linux-foundation.org, linux-hyperv@...r.kernel.org,
Haiyang Zhang <haiyangz@...rosoft.com>,
Jon Derrick <jonathan.derrick@...el.com>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Wei Liu <wei.liu@...nel.org>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Steve Wahl <steve.wahl@....com>,
Dimitri Sivanich <sivanich@....com>,
Russ Anderson <rja@....com>, linux-pci@...r.kernel.org,
Bjorn Helgaas <bhelgaas@...gle.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
xen-devel@...ts.xenproject.org, Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Marc Zyngier <maz@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Megha Dey <megha.dey@...el.com>,
Jason Gunthorpe <jgg@...lanox.com>,
Dave Jiang <dave.jiang@...el.com>,
Alex Williamson <alex.williamson@...hat.com>,
Jacob Pan <jacob.jun.pan@...el.com>,
Baolu Lu <baolu.lu@...el.com>,
Kevin Tian <kevin.tian@...el.com>,
Dan Williams <dan.j.williams@...el.com>
Subject: [patch V2 42/46] genirq/proc: Take buslock on affinity write
Until now interrupt chips which support setting affinity are nit locking
the associated bus lock for two reasons:
- All chips which support affinity setting do not use buslock because they just
can operated directly on the hardware.
- All chips which use buslock do not support affinity setting because
their interrupt chips are not capable. These chips are usually connected
over a bus like I2C, SPI etc. and have an interrupt output which is
conneted to CPU interrupt of some sort. So there is no way to set the
affinity on the chip itself.
Upcoming hardware which is PCIE based sports a non standard MSI(X) variant
which stores the MSI message in RAM which is associated to e.g. a device
queue. The device manages this RAM and writes have to be issued via command
queues or similar mechanisms which is obviously not possible from interrupt
disabled, raw spinlock held context.
The buslock mechanism of irq chips can be utilized to support that. The
affinity write to the chip writes to shadow state, marks it pending and the
irq chip's irq_bus_sync_unlock() callback handles the command queue and
wait for completion similar to the other chip operations on I2C or SPI
busses.
Change the locking in irq_set_affinity() to bus_lock/unlock to help with
that. There are a few other callers than the proc interface, but none of
them is affected by this change as none of them affects an irq chip with
bus lock support.
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
V2: New patch
---
kernel/irq/manage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -373,16 +373,16 @@ int irq_set_affinity_locked(struct irq_d
int __irq_set_affinity(unsigned int irq, const struct cpumask *mask, bool force)
{
- struct irq_desc *desc = irq_to_desc(irq);
+ struct irq_desc *desc;
unsigned long flags;
int ret;
+ desc = irq_get_desc_buslock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
if (!desc)
return -EINVAL;
- raw_spin_lock_irqsave(&desc->lock, flags);
ret = irq_set_affinity_locked(irq_desc_get_irq_data(desc), mask, force);
- raw_spin_unlock_irqrestore(&desc->lock, flags);
+ irq_put_desc_busunlock(desc, flags);
return ret;
}
Powered by blists - more mailing lists