[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ffe328f-2ba1-4799-5c6a-d48d88c0459d@omp.ru>
Date: Fri, 10 Dec 2021 14:14:15 +0300
From: Sergey Shtylyov <s.shtylyov@....ru>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC: <linux-ide@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Hans de Goede <hdegoede@...hat.com>,
Jens Axboe <axboe@...nel.dk>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>
Subject: Re: [PATCH v1 1/2] ata: libahci_platform: Get rid of dup message when
IRQ can't be retrieved
Hello!
On 12/10/21 1:44 PM, Andy Shevchenko wrote:
>>>>>>> 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)...
>>> 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)...
> ...
>
>>>>>>> - 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
>>>>
>>>>> 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.
>> 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
Powered by blists - more mailing lists