Hi,

On Wed, Mar 11, 2020 at 05:03:07PM +0100, Thomas Bogendoerfer wrote:

On Wed, Mar 11, 2020 at 06:42:10PM +0530, afzal mohammed wrote:

quoted

If IRQF_SHARED is passed, it exepcts a non-NULL dev_id, here it is
NULL, setup_irq() doesn't have any check like that.

so request_irq() is not a 1:1 replacement for our current setup_irq().
Or put it the another way our setup_irq() might be buggy, when used for
shared interrupts.

AFAIU, this causes problems only while freeing irq, but not sure. Seems
it is not happening with any of the cases in the diff.

quoted

So i think proper solution is to add a non NULL dev_id, as removing
IRQF_SHARED might affect some platforms that might be using that
interrupt line shared.

Patch with non-NULL dev_id below, it works w/ Nathan's test case.

I'm not sure, I like the adding of string pointers as dev_id arguments
in your patch. How can we make sure they are unique enough for the use
case ? I guess using handler as dev_id does a better job here.

There was one prior similar usage using string pointers, another way i
have seen is using irq no. itself, but then it has to be typecasted,
in file arch/mips/txx9/generic/pci.c,

        request_irq(irq, &i8259_interrupt, IRQF_SHARED,
                "cascade(i8259)", (void *)(long)irq);

[ but i think that double casting is not required, only (void *) might
suffice ]

If you prefer handler function pointer, i will use that.

And before doing that, lets clean up some of the IRQF_SHARED usage first.
All sni IRQF_SHARED can go away, the interrupt lines are exclusive there. 

loongson2ef/lemote-2f/irq.c: looks like the only user of
LOONGSON_NORTH_BRIDGE_IRQ, so IRQF_SHARED could go as well.
Could someone confirm that ?

All other need to stay, IMHO.

Okay, i am venturing into MIPS the first time as part of this patch
series, so no MIPS specific knowledge, just let me know
loongson2ef/lemote-2f case as well, i will prepare patch accordingly. 

And v4 is already in mips-next, so I need an incremental patch please.

Okay, i already sent a patch, it crossed your mail, i will make a new
patch based on the outcome of the discusson here.

Since there is some issue w/ lore.kernel.org, i send it again, but
both are not seen in archives.

Regards
afzal

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel