On Fri, Dec 10, 2021 at 02:14:15PM +0300, Sergey Shtylyov wrote:

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

quoted

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. :-)

And what is your point here exactly? If == 0 case happens, it will be
immediately WARN() and reported (I hope) since it will mean bug in the code.

   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)...

You mixed up HW IRQ with vIRQ. The former one may be 0 and it's completely valid case, while
the second one is not.

quoted

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.

What do you mean by that? vIRQ is handled by IRQ core, IRQ controller driver
just a mere provider of the resource. And those exceptions for vIRQ == 0
shouldn't be propagated to the platform code or so.

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)...

Again, do not mix vIRQ (about which Linus ranted) and HW IRQ.

...

quoted

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.

No problem. I just haven't got what other IRQ0 issues except fixing
platform_get_irq_optional() et al. could be possibly needed...

quoted

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)?

TL;DR: yes.

-- 
With Best Regards,
Andy Shevchenko