Ricardo,
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Certain types of interrupts, such as NMI, do not have an associated vector.
> They, however, target specific CPUs. Thus, when assigning the destination
> CPU, it is beneficial to select the one with the lowest number of
> vectors.
Why i
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Currently, the delivery mode of all interrupts is set to the mode of the
> APIC driver in use. There are no restrictions in hardware to configure the
> delivery mode of each interrupt individually. Also, certain IRQs need
> to be
s/IRQ/interrupt/
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> There are no restrictions in hardware to set MSI messages with its
> own delivery mode.
"messages with its own" ? Plural/singular confusion.
> Use the mode specified in the provided IRQ hardware
> configuration data. Since most of the IRQs are
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Vectors are meaningless when allocating IRQs with NMI as the delivery
> mode.
Vectors are not meaningless. NMI has a fixed vector.
The point is that for a fixed vector there is no vector management
required.
Can you spot the difference?
> In s
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> The Intel IOMMU interrupt remapping driver already programs correctly the
> delivery mode of individual irqs as per their irq_data. Improve handling
> of NMIs. Allow only one irq per NMI. Also, it is not necessary to cleanup
> irq vectors after up
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>
> + if (info->flags & X86_IRQ_ALLOC_AS_NMI) {
> + /* Only one IRQ per NMI */
> + if (nr_irqs != 1)
> + return -EINVAL;
See previous reply.
___
iommu ma
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> + *
> + * Also, NMIs do not have an associated vector. No need for cleanup.
They have a vector and what the heck is this cleanup comment for here?
There is nothing cleanup alike anywhere near.
Adding confusing comments is worse than ad
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Programming an HPET channel as periodic requires setting the
> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
> register must be written twice (once for the comparator value and once for
> the periodic value). Since this pro
On Fri, May 06 2022 at 23:41, Thomas Gleixner wrote:
> On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>> Programming an HPET channel as periodic requires setting the
>> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
>> register must be writte
On Thu, May 05 2022 at 17:00, Ricardo Neri wrote:
> Add a NMI_WATCHDOG as a new category of NMI handler. This new category
> is to be used with the HPET-based hardlockup detector. This detector
> does not have a direct way of checking if the HPET timer is the source of
> the NMI. Instead, it indire
On Thu, May 05 2022 at 17:00, Ricardo Neri wrote:
> + if (is_hpet_hld_interrupt(hdata)) {
> + /*
> + * Kick the timer first. If the HPET channel is periodic, it
> + * helps to reduce the delta between the expected TSC value and
> + * its actual
On Tue, May 10 2022 at 21:16, Nicholas Piggin wrote:
> Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am:
>> +/*
>> + * If in use, the HPET hardlockup detector relies on tsc_khz.
>> + * Reconfigure it to make use of the refined tsc_khz.
>> + */
>> +lockup_detector_rec
On Fri, May 13 2022 at 11:03, Ricardo Neri wrote:
> On Fri, May 06, 2022 at 11:12:20PM +0200, Thomas Gleixner wrote:
>> Why would a NMI ever end up in this code? There is no vector management
>> required and this find cpu exercise is pointless.
>
> But even if the NMI has
On Fri, May 13 2022 at 16:45, Ricardo Neri wrote:
> On Fri, May 13, 2022 at 10:50:09PM +0200, Thomas Gleixner wrote:
>> > Also, if lapic_nmi_controller.irq_set_affinity() is NULL, then irq_chips
>> > INTEL-IR, AMD-IR, those using msi_domain_set_affinity() need to check for
On Fri, May 13 2022 at 14:19, Ricardo Neri wrote:
> On Fri, May 06, 2022 at 11:41:13PM +0200, Thomas Gleixner wrote:
>> The argument about not bloating the code
>> with an "obvious???" function which is quite small is slightly beyond my
>> comprehension level.
>
On Fri, May 13 2022 at 15:16, Ricardo Neri wrote:
> On Mon, May 09, 2022 at 04:03:39PM +0200, Thomas Gleixner wrote:
>> > + /* If we are here, IPI shorthands are enabled. */
>> > + apic->send_IPI_allbutself(NMI_VECTOR);
>>
>&
On Thu, Mar 25 2021 at 17:08, Marc Zyngier wrote:
> Megha Dey wrote:
>> @@ -434,6 +434,12 @@ int __msi_domain_alloc_irqs(struct irq_domain *domain,
>> struct device *dev,
>> if (ret)
>> return ret;
>>
>> +if (ops->msi_alloc_store) {
>> +ret = ops->msi_alloc_sto
On Thu, Mar 25 2021 at 17:23, Marc Zyngier wrote:
>> +/**
>> + * irq_set_auxdata - Set auxiliary data
>> + * @irq:Interrupt to update
>> + * @which: Selector which data to update
>> + * @auxval: Auxiliary data value
>> + *
>> + * Function to update auxiliary data for an interrupt, e.g. to upda
On Thu, Mar 25 2021 at 17:43, Marc Zyngier wrote:
> On Fri, 26 Feb 2021 20:11:16 +,
> Megha Dey wrote:
>> +
>> +#include
>> +
>> +#ifdef CONFIG_IMS_MSI_ARRAY
>
> Given that this covers the whole driver, what is this #defined used
> for? You might as well make the driver depend on this config
On Fri, Mar 26 2021 at 10:32, Marc Zyngier wrote:
> On Thu, 25 Mar 2021 18:59:48 +,
> Thomas Gleixner wrote:
>> Though that leaves the question of the data type for 'val'. While u64 is
>> probably good enough for most stuff, anything which needs more than that
>
On Tue, May 04 2021 at 12:10, Ricardo Neri wrote:
> In x86 there is not an IRQF_NMI flag that can be used to indicate the
There exists no IRQF_NMI flag at all. No architecture provides that.
> delivery mode when requesting an interrupt (via request_irq()). Thus,
> there is no way for the interrup
On Tue, May 04 2021 at 12:10, Ricardo Neri wrote:
Resending as the original one did not make it on the list because of
fatfingers. Sorry for the noise.
> In x86 there is not an IRQF_NMI flag that can be used to indicate the
There exists no IRQF_NMI flag at all. No architecture provides that.
>
work, this cannot result in a regression
except for related out of tree train-wrecks, but they are broken already
today.
Fixes: 20f0afd1fb3d ("x86/mmu: Allocate/free a PASID")
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
---
See also: https://lore.kernel.org/lkml/874
On Mon, May 31 2021 at 10:43, Borislav Petkov wrote:
> On Sat, May 29, 2021 at 11:17:30AM +0200, Thomas Gleixner wrote:
>> #2 is broken beyond repair. The comment in the code claims that it is safe
>>to invoke this in an IPI, but that's just wishful thinking.
>>
&g
On Wed, Jun 02 2021 at 12:14, Borislav Petkov wrote:
> On Sat, May 29, 2021 at 11:17:30AM +0200, Thomas Gleixner wrote:
>> --- a/arch/x86/include/asm/disabled-features.h
>> +++ b/arch/x86/include/asm/disabled-features.h
>> @@ -56,11 +56,8 @@
>> # define DI
On Mon, Sep 20 2021 at 19:23, Fenghua Yu wrote:
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index c8def1b7f8fb..8a89b2cecd77 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -1289,3 +1289,62 @@ int proc_pid_arch_status(struct seq
On Mon, Sep 20 2021 at 19:23, Fenghua Yu wrote:
>
> +#ifdef CONFIG_INTEL_IOMMU_SVM
> +void pasid_put(struct task_struct *tsk, struct mm_struct *mm);
> +#else
> +static inline void pasid_put(struct task_struct *tsk, struct mm_struct *mm)
> { }
> +#endif
This code is again defining that PASID is
On Thu, Sep 23 2021 at 09:40, Tony Luck wrote:
> On Thu, Sep 23, 2021 at 04:36:50PM +0200, Thomas Gleixner wrote:
>> This code is again defining that PASID is entirely restricted to
>> INTEL. It's true, that no other vendor supports this, but PASID is
>> a n
On Thu, Sep 23 2021 at 19:48, Thomas Gleixner wrote:
> On Thu, Sep 23 2021 at 09:40, Tony Luck wrote:
>
> fpu_write_task_pasid() can just grab the pasid from current->mm->pasid
> and be done with it.
>
> The task exit code can just call iommu_pasid_put_task_ref() from th
Fenghua,
On Fri, Sep 24 2021 at 16:12, Fenghua Yu wrote:
> On Fri, Sep 24, 2021 at 03:18:12PM +0200, Thomas Gleixner wrote:
>> But OTOH why do you need a per task reference count on the PASID at all?
>>
>> The PASID is fundamentaly tied to the mm and the mm can't go
On Fri, Sep 25 2020 at 17:49, Peter Zijlstra wrote:
> Here it looks like this:
>
> [1.830276] BUG: kernel NULL pointer dereference, address:
> [1.838043] #PF: supervisor instruction fetch in kernel mode
> [1.844357] #PF: error_code(0x0010) - not-present page
> [1.85
: 9006c133a422 ("x86/msi: Use generic MSI domain ops")
Reported-by: Qian Cai
Reported-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/msi.c |2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -30
On Sat, Sep 26 2020 at 14:38, Vasily Gorbik wrote:
> On Fri, Sep 25, 2020 at 09:54:52AM -0400, Qian Cai wrote:
> Yes, as well as on mips and sparc which also don't FORCE_PCI.
> This seems to work for s390:
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index b0b7acf07eb8..41136fbe909b 100
On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
>> #9 is obviously just for the folks interested in IMS
>>
>
> I see that the tip tree (as of 9/29) has most of these patches but
> notice that the DEV_MSI related patches
>
On Wed, Sep 30 2020 at 08:43, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
>> On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
>> > On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
>> >> #9is obviously just f
Megha,
On Wed, Sep 30 2020 at 10:25, Megha Dey wrote:
> On 9/30/2020 8:20 AM, Thomas Gleixner wrote:
>>>> Your IMS patches? Why do you need something special again?
>
> By IMS patches, I meant your IMS driver patch that was updated (as it
> was untested, it had some compi
Yan,
On Wed, Sep 30 2020 at 21:29, Zi Yan wrote:
> I am running linux-next on my Dell R630 and the system crashed at boot
> time. I bisected linux-next and got to your commit:
>
> x86/msi: Consolidate MSI allocation
>
> The crash log is below and my .config is attached.
>
> [ 11.840905] int
Yan,
On Thu, Oct 01 2020 at 09:39, Zi Yan wrote:
> On 1 Oct 2020, at 4:22, Thomas Gleixner wrote:
>> Can you please test:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/irq
>>
>> which contains fixes and if it still crashes provide the
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> -static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg)
> +static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg,
> int dmar)
bool dmar?
> +/*
> + * The Intel IOMMU (ab)uses the high bits of the MSI
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
>
> #else /* CONFIG_SMP */
>
> +#define irq_default_affinity (NULL)
...
> static int alloc_descs(unsigned int start, unsigned int cnt, int node,
> const struct irq_affinity_desc *affinity,
> +const
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
> It already takes an array of affinities for each individual irq being
> allocated but that's awkward to allocate and populate in the case
> where they're all the same and inherited from the irqdomain, so pass
> the defa
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
>
> This is the maximum possible set of CPUs which can be used. Use it
> to calculate the default affinity requested from __irq_alloc_descs()
> by first attempting to find the intersection with irq_default_affinity,
> or
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> +/**
> + * irq_domain_set_affinity - Set maximum CPU affinity for domain
> + * @parent: Domain to set affinity for
> + * @affinity:Pointer to cpumask, consumed by domain
> + *
> + * Sets the maximal set of CPUs to which interrupts in t
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
>
> This is the mask of CPUs to which IRQs can be delivered without interrupt
> remapping.
>
> +/* Mask of CPUs which can be targeted by non-remapped interrupts. */
> +cpumask_t x86_non_ir_cpumask = { CPU_BITS_ALL };
W
On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> From: David Woodhouse
>
> When interrupt remapping isn't enabled, only the first 255 CPUs can
No, only CPUs with an APICid < 255
> receive external interrupts. Set the appropriate max affinity for
> the IOAPIC and MSI IRQ domains accor
On Wed, Oct 07 2020 at 08:48, David Woodhouse wrote:
> On Tue, 2020-10-06 at 23:54 +0200, Thomas Gleixner wrote:
>> On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
> This is the case I called out in the cover letter:
>
> This patch series implements a per-domain "ma
On Wed, Oct 07 2020 at 08:19, David Woodhouse wrote:
> On Tue, 2020-10-06 at 23:26 +0200, Thomas Gleixner wrote:
>> On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote:
>> > From: David Woodhouse
>> >
>> > This is the maximum possible set of CPUs which can b
On Wed, Oct 07 2020 at 14:08, David Woodhouse wrote:
> On 7 October 2020 13:59:00 BST, Thomas Gleixner wrote:
>>On Wed, Oct 07 2020 at 08:48, David Woodhouse wrote:
>>> To fix *that* case, we really do need the whole series giving us per-
>>> domain restricted affini
On Wed, Oct 07 2020 at 16:05, David Woodhouse wrote:
> On Wed, 2020-10-07 at 16:05 +0200, Thomas Gleixner wrote:
>> The top most MSI irq chip does not even have a compose function, neither
>> for the remap nor for the vector case. The composition is done by the
>> parent domai
On Wed, Oct 07 2020 at 15:10, David Woodhouse wrote:
> On Wed, 2020-10-07 at 15:37 +0200, Thomas Gleixner wrote:
>> What is preventing you to change the function signature? But handing
>> down irqdomain here is not cutting it. The right thing to do is to
>> replace
On Wed, Oct 07 2020 at 15:23, David Woodhouse wrote:
> On Wed, 2020-10-07 at 16:05 +0200, Thomas Gleixner wrote:
>> On Wed, Oct 07 2020 at 14:08, David Woodhouse wrote:
>> > On 7 October 2020 13:59:00 BST, Thomas Gleixner wrote:
>> > > On Wed, Oct 07 2020 a
On Wed, Oct 07 2020 at 16:46, David Woodhouse wrote:
> The PCI MSI domain, HPET, and even the IOAPIC are just the things out
> there on the bus which might perform those physical address cycles. And
> yes, as you say they're just a message store sending exactly the
> message that was composed for t
On Wed, Oct 07 2020 at 17:11, David Woodhouse wrote:
> On 7 October 2020 16:57:36 BST, Thomas Gleixner wrote:
>>There is not lot's of nastiness.
>
> OK, but I think we do have to cope with the fact that the limit is
> dynamic, and a CPU might be added which widens the
On Thu, Oct 08 2020 at 08:21, David Woodhouse wrote:
> On Wed, 2020-10-07 at 17:57 +0200, Thomas Gleixner wrote:
>> Multiqueue devices want to have at max 1 queue per CPU or if the device
>> has less queues than CPUs they want the queues to have a fixed
>> association to a s
On Thu, Oct 08 2020 at 12:10, David Woodhouse wrote:
> On Thu, 2020-10-08 at 11:34 +0200, Thomas Gleixner wrote:
>> The overall conclusion for this is:
>>
>> 1) X2APIC support on bare metal w/o irq remapping is not going to
>> happen unless you:
>>
>&g
On Wed, Oct 28 2020 at 13:49, Kees Cook wrote:
> On Sat, Oct 24, 2020 at 10:35:15PM +0100, David Woodhouse wrote:
>> +memset(&msg, 0, sizeof(*msg);
>
> This should be:
>
> + memset(msg, 0, sizeof(*msg);
memset(msg, 0, sizeof(*msg));
Then it compiles _and_ is correct :)
___
Arnd,
On Thu, Oct 29 2020 at 10:51, Arnd Bergmann wrote:
> On Thu, Oct 29, 2020 at 8:04 AM Paolo Bonzini wrote:
>> On 28/10/20 22:20, Arnd Bergmann wrote:
>> > Avoid this by renaming the global 'apic' variable to the more descriptive
>> > 'x86_system_apic'. It was originally called 'genapic', but
On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> On 29/10/20 17:56, Arvind Sankar wrote:
>>> For those two just add:
>>> struct apic *apic = x86_system_apic;
>>> before all the assignments.
>>> Less churn and much better code.
>>>
>> Why would it be better code?
>>
>
> I think he means the
Jason,
(trimmed CC list a bit)
On Thu, Nov 12 2020 at 08:55, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
> They were unable to bisect further into the series because some of the
> interior commits don't boot :(
>
> When we try to
On Thu, Nov 12 2020 at 15:15, Thomas Gleixner wrote:
> On Thu, Nov 12 2020 at 08:55, Jason Gunthorpe wrote:
>> On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
>> They were unable to bisect further into the series because some of the
>> interior commits don&#x
("iommm/vt-d: Store irq domain in struct device")
Reported-by: Jason Gunthorpe
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/dmar.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar
On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote:
> The recent changes to store the MSI irqdomain pointer in struct device
> missed that Intel DMAR does not register virtual function devices. Due to
> that a VF device gets the plain PCI-MSI domain assigned and then issues
> compat
On Fri, Nov 13 2020 at 09:19, Marc Zyngier wrote:
> On 2020-11-12 21:34, Thomas Gleixner wrote:
>> That would allow to add a irq_find_matching_fwspec() based lookup to
>> pci_msi_get_device_domain().
>
> Just so that I understand the issue: is the core of the problem that
>
Geert,
On Mon, Nov 16 2020 at 10:47, Geert Uytterhoeven wrote:
> On Thu, Nov 12, 2020 at 8:16 PM Thomas Gleixner wrote:
>> The recent changes to store the MSI irqdomain pointer in struct device
>> missed that Intel DMAR does not register virtual function devices. Due to
>>
On Wed, Sep 29 2021 at 11:54, Peter Zijlstra wrote:
> On Fri, Sep 24, 2021 at 04:03:53PM -0700, Andy Lutomirski wrote:
>> I think the perfect and the good are a bit confused here. If we go for
>> "good", then we have an mm owning a PASID for its entire lifetime. If
>> we want "perfect", then we sh
On Wed, Sep 29 2021 at 09:59, Andy Lutomirski wrote:
> On 9/29/21 05:28, Thomas Gleixner wrote:
>> Looking at that patch again, none of this muck in fpu__pasid_write() is
>> required at all. The whole exception fixup is:
>>
>> if (!user_mode(regs))
&g
On Wed, Sep 29 2021 at 11:31, Tony Luck wrote:
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index a58800973aed..5a3c87fd65de 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -528,6 +528,32 @@ static enum kernel_gp_hint get_kernel_gp_address(struct
>
Create struct msi_device_data and add a pointer of that type to struct
dev_msi_info, which is part of struct device. Provide an allocator function
which can be invoked from the MSI interrupt allocation code pathes.
Signed-off-by: Thomas Gleixner
---
include/linux/device.h |5 +
include
: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Will Deacon
Cc: Santosh Shilimkar
Cc: iommu@lists.linux-foundation.org
Cc: dmaeng...@vger.kernel.org
---
drivers/base/platform-msi.c | 12 ++--
drivers/dma/ti/k3-udma.c|4 ++--
drivers/iommu/arm/arm-smmu
Allocate MSI device data on first use, i.e. when a PCI driver invokes one
of the PCI/MSI enablement functions.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci
Allocate the MSI device data on first invocation of the allocation function
for platform MSI private data.
Signed-off-by: Thomas Gleixner
---
drivers/base/platform-msi.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/base/platform-msi.c
+++ b/drivers/base
This is the second part of [PCI]MSI refactoring which aims to provide the
ability of expanding MSI-X vectors after enabling MSI-X.
The first part of this work can be found here:
https://lore.kernel.org/r/20211126222700.862407...@linutronix.de
This second part has the following important chan
Remove the register lock from struct device and use the one in
struct msi_device_data.
Signed-off-by: Thomas Gleixner
---
drivers/base/core.c|1 -
drivers/pci/msi/msi.c |2 +-
include/linux/device.h |2 --
3 files changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/base
Allocate the MSI device data on first invocation of the allocation function.
Signed-off-by: Thomas Gleixner
Cc: Stuart Yoder
Cc: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-msi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/bus/fsl-mc/fsl-mc-msi.c
Allocate the MSI device data on first invocation of the allocation function.
Signed-off-by: Thomas Gleixner
Cc: Nishanth Menon
Cc: Tero Kristo
Cc: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/soc/ti/ti_sci_inta_msi.c |4
1 file changed, 4 insertions
Add new allocation functions which can be activated by domain info
flags. They store the groups pointer in struct msi_device_data.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h | 12 +++-
kernel/irq/msi.c| 42 --
2 files changed
Set the domain info flag which makes the core code handle sysfs groups and
put an explicit invocation into the legacy code.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/irqdomain.c |2 +-
drivers/pci/msi/legacy.c|6 +-
drivers/pci/msi/msi.c | 23
Set the domain info flag and remove the local sysfs code.
Signed-off-by: Thomas Gleixner
---
drivers/base/platform-msi.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -23,7 +23,6 @@
struct
No more users. Refactor the core code accordingly.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h | 12 ---
kernel/irq/msi.c| 53 +++-
2 files changed, 20 insertions(+), 45 deletions(-)
--- a/include/linux/msi.h
+++ b
It's hard to distinguish what platform_msi_domain_alloc() and
platform_msi_domain_alloc_irqs() are about. Make the distinction more
explicit and add comments which explain the use cases properly.
Signed-off-by: Thomas Gleixner
---
drivers/base/platform-msi.c |
Storing the platform private data in a MSI descriptor is sloppy at
best. The data belongs to the device and not to the descriptor.
Add a pointer to struct msi_device_data and store the pointer there.
Signed-off-by: Thomas Gleixner
---
drivers/base/platform-msi.c | 79
All non PCI/MSI usage variants have data structures in struct msi_desc with
only one member: xxx_index. PCI/MSI has a entry_nr member.
Add a common msi_index member to struct msi_desc so all implementations can
share it which allows further consolidation.
Signed-off-by: Thomas Gleixner
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
---
drivers/bus/fsl-mc/fsl-mc-allocator.c |2 +-
drivers/bus/fsl-mc/fsl-mc-msi.c |6 +++---
include/linux/msi.h | 10 --
3 files changed, 4
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
Cc: linux-arm-ker...@lists.infradead.org
Cc: iommu@lists.linux-foundation.org
Cc: dmaeng...@vger.kernel.org
---
drivers/base/platform-msi.c | 10 +-
drivers/dma
Use the common msi_index member and get rid of the pointless wrapper struct.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/irq-ti-sci-inta.c |2 +-
drivers/soc/ti/ti_sci_inta_msi.c |6 +++---
include/linux/msi.h | 16 ++--
3 files changed, 6 insertions
The usage of msi_desc::pci::entry_nr is confusing at best. It's the index
into the MSI[X] descriptor table.
Use msi_desc::msi_index which is shared between all MSI incarnations
instead of having a PCI specific storage for no value.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/plat
Add a properties field which allows core code to store information for easy
retrieval in order to replace MSI descriptor fiddling.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h | 17 +
kernel/irq/msi.c| 12
2 files changed, 29 insertions(+)
--- a
Store the properties which are interesting for various places so the MSI
descriptor fiddling can be removed.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -244,6 +244,8
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
---
arch/x86/pci/xen.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -399,9 +399,7 @@ static void xen_teardown_msi_irqs(struct
static void
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/msi.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -160,11 +160,8 @@ static struct irq_chip pci_msi_controlle
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
Cc: x...@kernel.org
---
kernel/irq/msi.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -114,21 +114,8 @@ int msi_setup_device_data(struct
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/platforms/cell/axon_msi.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -199,7 +199,7
instead of fiddling with MSI descriptors.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/platforms/pseries/msi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -447,9 +447,9 @@ static int
Provide a domain info flag which makes the core code check for a contiguous
MSI-X index on allocation. That's simpler than checking it at some other
domain callback in architecture code.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/irqdomain.c | 16 ++--
include/linux/
Set the domain info flag and remove the check.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/platforms/pseries/msi.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
This allows drivers to retrieve the Linux interrupt number instead of
fiddling with MSI descriptors.
msi_get_virq() returns the Linux interrupt number or 0, __msi_get_virq()
has more detailed return codes so pci_irq_vector() can use it as well.
Signed-off-by: Thomas Gleixner
---
include/linux
Use __msi_get_vector() and handle the return values to be compatible.
No functional change intended.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi
Replace open coded MSI descriptor chasing and use the proper accessor
functions instead.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
Let the core code fiddle with the MSI descriptor retrieval.
Signed-off-by: Thomas Gleixner
Cc: Mark Rutland
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/perf/arm_smmuv3_pmu.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/perf
Let the core code fiddle with the MSI descriptor retrieval.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm
301 - 400 of 584 matches
Mail list logo
