lkml.org 
[lkml]   [2023]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PIC probing code from e179f6914152 failing
Date
On Mon, Oct 23 2023 at 11:17, Mario Limonciello wrote:
> On 10/23/2023 10:59, Thomas Gleixner wrote:
>>> IOW NULL pic case has IORESOURCE_DISABLED / IORESOURCE_UNSET
>>
>> So the real question is WHY are the DISABLED/UNSET flags not set in the
>> PIC case?

Do you have an answer for this?

>>> NULL case:
>>> handler: handle_edge_irq
>>> dstate: 0x3740c208
>>> IRQ_TYPE_LEVEL_LOW
>>>
>>> PIC case:
>>> handler: handle_fasteoi_irq
>>> dstate: 0x3740e208
>>> IRQ_TYPE_LEVEL_LOW
>>> IRQD_LEVEL
>>>
>>> I guess something related to the callpath for mp_register_handler().
>>
>> Guessing is not helpful.
>>
>> There is a difference in how the allocation info is set up when legacy
>> PIC is enabled, but that does not explain the above resource flag
>> difference.
>
> I did a pile of printks and that's how I realized it's because of the
> missing call to mp_register_handler() which is dependent upon what
> appeared to me to be a superfluous number of legacy IRQs check (patch 1
> in my solution).

What exactly is superfluous about these legacy checks?

Thanks,

tglx

\
 
 \ /
  Last update: 2023-10-23 19:51    [W:0.134 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site