Hello!

On 12/10/21 1:44 PM, Andy Shevchenko wrote:

quoted

quoted

quoted

quoted

quoted

quoted

While at it, drop redundant check for 0 as platform_get_irq() spills
out a big WARN() in such case.

   And? IRQ0 is still returned! :-(

It should not be returned in the first place.

   But it still is, despite the WARN(), right?

So, you admit that there is a code which does that?

   I admit *what*?! That platfrom_get_irq() and its ilk return IRQ0 while they
shouldn't? =)

That there is a code beneath platform_get_irq() that returns 0, yes.

   Look at the ACPI-specific GpioInt handling code (just above the out_not_found label) --
I'm not sure the check there is correct -- I'm not very familiar with ACPI, you seem to
know it much better. :-)
   Also, 0 can be specified via the normal IRQ resource. I know of e.g. the Alchemy MIPS SoCs
that have IRQ0 used by UART0; luckily, currently SoC IRQs are mapped starting at Linux IRQ8
(but it wasn't the case in the 2.6.1x time frame where we had issue with the serial driver)...

quoted

quoted

That code should be fixed first. Have you sent a patch?

   Which code?! You got me totally muddled. =)

Above mentioned.

   What needs to be fixed in this case is the interrupt controller driver. Quoting Linus
(imprecisely :-)), IRQ #s should be either mapped starting with #1 or IRQ0 remapped at
the end of the controller's interrupt range... I currently have no information on the 
platforms requiring such kind of fixing (Alchemy don't seem to need it now)...

...

quoted

quoted

quoted

quoted

quoted

quoted

-	if (!irq)
-		return -EINVAL;

   This is prermature -- let's wait till my patch that stops returning IRQ0 from
platform_get_irq() and friends gets merged....

What patch?

   https://marc.info/?l=linux-kernel&m=163623041902285

quoted

Does it fix platform_get_irq_optional()?

   Of course! :-)

Can you share link to lore.kernel.org, please?
It will make much easier to try and comment.

   I don't know how to uise it yet, and I'm a little busy with other IRQ0 issues ATM,

   A little bit, I meant to type.

quoted

so I'm afraid you're on your own here...

lore.kernel.org is the official mailing list archive for Linux kernel work
AFAIU. Other sites may do whatever they want with that information, so -->
they are unreliable. If you wish to follow the better process, use
lore.kernel.org. Understanding how it works takes no more than 5 minutes
by engineer with your kind of experience with Linux kernel development.

   OK, I'll explore this archive when I have time. BTW, does it keep the messages not
posted to LKML (I tend to only CC LKML if there's no other mailing lists to post to)?

MBR, Sergey