Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-27 Thread Marc Zyngier
On 2020-11-27 12:45, John Garry wrote: On 27/11/2020 09:57, Marc Zyngier wrote: If I understand the code correctly, MSI_ALLOC_FLAGS_SHARED_DEVICE is supposed to be set in info->flags in platform_msi_set_desc(), but this is called per-msi after its_msi_prepare(), so we don't the flags set at th

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-27 Thread John Garry
On 27/11/2020 09:57, Marc Zyngier wrote: If I understand the code correctly, MSI_ALLOC_FLAGS_SHARED_DEVICE is supposed to be set in info->flags in platform_msi_set_desc(), but this is called per-msi after its_msi_prepare(), so we don't the flags set at the right time. That's how it looks to me...

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-27 Thread Marc Zyngier
On 2020-11-26 16:52, John Garry wrote: Hi Marc, https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks ok, I'll have a look I tried that and it doesn't look to work. I find that for the its_msi_prepare() call, its_dev->shared does not get set, as MSI_ALLOC

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-26 Thread John Garry
Hi Marc, https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks ok, I'll have a look I tried that and it doesn't look to work. I find that for the its_msi_prepare() call, its_dev->shared does not get set, as MSI_ALLOC_FLAGS_SHARED_DEVICE is not set in inf

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-26 Thread John Garry
Hi Marc, I did: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks ok, I'll have a look You still should be able to enable my favorite CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, while the distro still boot. But I'll just test if you want. Ah! Let me try that

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-26 Thread Marc Zyngier
Hi John, On 2020-11-26 10:47, John Garry wrote: Hi Marc, Right, I did consider this. FWIW, I've pushed my hack branch[1] Did you miss that reference? I did: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks out with a couple of patches for you to

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-26 Thread John Garry
Hi Marc, Right, I did consider this. FWIW, I've pushed my hack branch[1] Did you miss that reference? out with a couple of patches for you to try (the top 3 patches). They allow platform-MSI domains created by devices (mbigen, ICU) to be advertised as shared between devices, so that the lo

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-25 Thread Marc Zyngier
On 2020-11-24 17:38, John Garry wrote: Hi Marc, So initially in the msi_prepare method we setup the its dev - this is from the mbigen probe. Then when all the irqs are unmapped later for end device driver removal, we release this its device in its_irq_domain_free(). But I don't see anything to

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-24 Thread John Garry
Hi Marc, So initially in the msi_prepare method we setup the its dev - this is from the mbigen probe. Then when all the irqs are unmapped later for end device driver removal, we release this its device in its_irq_domain_free(). But I don't see anything to set it up again. Is it improper to have

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-24 Thread Marc Zyngier
On 2020-11-23 15:45, John Garry wrote: Hi John, But it looks like there is more to it than that, which I'm worried is far from non-trivial. For example, just calling irq_dispose_mapping() for removal and then plaform_get_irq()->acpi_get_irq() second time fails as it looks like more tidy-up is n

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-23 Thread John Garry
Hi Marc, So is there a reason for which irq dispose mapping is not a requirement for drivers when finished with the irq? because of shared interrupts? For a bunch of reasons: IRQ number used to be created 1:1 with their physical counterpart, so there wasn't a need to "get rid" of the associate

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-23 Thread Marc Zyngier
Hi John, On 2020-11-23 12:54, John Garry wrote: Hi Marc, Right, but if the driver is removed then the interrupts should be deallocated, right? When removing the driver we just call free_irq(), which removes the handler and disables the interrupt. But about the irq_desc, this is created whe

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-23 Thread John Garry
Hi Marc, Right, but if the driver is removed then the interrupts should be deallocated, right? When removing the driver we just call free_irq(), which removes the handler and disables the interrupt. But about the irq_desc, this is created when the mapping is created in irq_create_fwspec_mapp

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-22 Thread Marc Zyngier
On Fri, 20 Nov 2020 11:52:09 +, John Garry wrote: > > Hi Thomas, > > >> Just mentioning a couple of things here, which could be a clue to what > >> is going on: > >> - the device is behind mbigen secondary irq controller > >> - the flow in the LLDD is to allocate all 128 interrupts during pr

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-20 Thread John Garry
Hi Thomas, Just mentioning a couple of things here, which could be a clue to what is going on: - the device is behind mbigen secondary irq controller - the flow in the LLDD is to allocate all 128 interrupts during probe, but we only register handlers for a subset with device managed API Right,

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-19 Thread Thomas Gleixner
On Thu, Nov 19 2020 at 19:56, John Garry wrote: 3) Interrupt has already been switched to managed. Double init is not really a good sign either. >>> I just tested that and case 3) would be a problem. I don't see us >>> clearing the managed flag when free'ing the interrupt. So wit

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-19 Thread John Garry
Hi Thomas, 3) Interrupt has already been switched to managed. Double init is not really a good sign either. I just tested that and case 3) would be a problem. I don't see us clearing the managed flag when free'ing the interrupt. So with CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, we attempt thi

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-19 Thread Thomas Gleixner
On Thu, Nov 19 2020 at 09:31, John Garry wrote: >> 1) Interrupt does not exist. Definitely a full fail >> >> 2) Interrupt is already started up. Not a good idea on init() and >> a clear fail. >> >> 3) Interrupt has already been switched to managed. Double init is not >> really a g

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-19 Thread John Garry
Hi Thomas, +int irq_update_affinity_desc(unsigned int irq, +struct irq_affinity_desc *affinity) Just a note on the return value, in the only current callsite - platform_get_irqs_affinity() - we don't check the return value and propagate the error. This is because we

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-18 Thread Thomas Gleixner
John, On Wed, Nov 18 2020 at 11:34, John Garry wrote: >> +/** >> + * irq_update_affinity_desc - Update affinity management for an interrupt >> + * @irq:The interrupt number to update >> + * @affinity: Pointer to the affinity descriptor >> + * >> + * This interface can be used to configur

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-18 Thread John Garry
Hi Thomas, Sorry for the delay. No worries, Thanks for the effort. Supporting this truly on x86 needs some more thought and surgery, but for ARM it should not matter. ok, as long as you are content not to support x86 atm. I made a few tweaks to your original code. See below. I think

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-17 Thread Thomas Gleixner
On Mon, Nov 02 2020 at 21:35, Thomas Gleixner wrote: > On Mon, Nov 02 2020 at 17:32, John Garry wrote: > Correct. I have a halfways working solution for that, but I need to fix > some other thing first. Sorry for the delay. Supporting this truly on x86 needs some more thought and surgery, but for

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-02 Thread Thomas Gleixner
On Mon, Nov 02 2020 at 17:32, John Garry wrote: > On 28/10/2020 18:22, Thomas Gleixner wrote: >> But all of this can't work on x86 due to the way how vector allocation >> works. Let me think about that. > > Is the problem that we reserve per-cpu managed interrupt space when > allocated irq vectors

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-11-02 Thread John Garry
On 28/10/2020 18:22, Thomas Gleixner wrote: On Wed, Oct 28 2020 at 20:33, John Garry wrote: Hi Thomas, +int irq_update_affinity_desc(unsigned int irq, +struct irq_affinity_desc *affinity) +{ + unsigned long flags; + struct irq_desc *desc = irq_get_de

[PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-10-28 Thread John Garry
Add a function to allow the affinity of an interrupt be switched to managed, such that interrupts allocated for platform devices may be managed. Suggested-by: Thomas Gleixner Signed-off-by: John Garry --- include/linux/interrupt.h | 8 kernel/irq/manage.c | 19 ++

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

2020-10-28 Thread Thomas Gleixner
On Wed, Oct 28 2020 at 20:33, John Garry wrote: > > +int irq_update_affinity_desc(unsigned int irq, > + struct irq_affinity_desc *affinity) > +{ > + unsigned long flags; > + struct irq_desc *desc = irq_get_desc_lock(irq, &flags, 0); > + > + if (!desc) > +