From: Thomas Gleixner <tglx@linutronix.de>
To: Mario Limonciello <mario.limonciello@amd.com>,
Hans de Goede <hdegoede@redhat.com>,
kys@microsoft.com, hpa@linux.intel.com
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>
Subject: Re: PIC probing code from e179f6914152 failing
Date: Mon, 23 Oct 2023 19:50:48 +0200 [thread overview]
Message-ID: <87lebtcjnr.ffs@tglx> (raw)
In-Reply-To: <08889426-e8e7-491b-bcc6-fd001bad3269@amd.com>
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
next prev parent reply other threads:[~2023-10-23 17:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 18:50 PIC probing code from e179f6914152 failing Mario Limonciello
2023-10-18 22:50 ` Thomas Gleixner
2023-10-19 16:39 ` David Lazăr
2023-10-19 21:20 ` Mario Limonciello
2023-10-20 3:43 ` Mario Limonciello
2023-10-20 15:16 ` Hans de Goede
2023-10-20 17:13 ` Mario Limonciello
2023-10-23 15:59 ` Thomas Gleixner
2023-10-23 16:17 ` Mario Limonciello
2023-10-23 17:50 ` Thomas Gleixner [this message]
2023-10-23 17:59 ` Mario Limonciello
2023-10-25 9:23 ` Thomas Gleixner
2023-10-25 14:41 ` Mario Limonciello
2023-10-25 15:25 ` Mario Limonciello
2023-10-25 15:25 ` David Lazar
2023-10-25 17:31 ` Thomas Gleixner
2023-10-25 17:37 ` Rafael J. Wysocki
2023-10-25 21:04 ` [PATCH] x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility, Thomas Gleixner
2023-10-25 22:11 ` Mario Limonciello
2023-10-26 9:27 ` Re: Thomas Gleixner
2023-10-26 8:17 ` [PATCH] x86/i8259: Skip probing when ACPI/MADT advertises PCAT compatibility Hans de Goede
2023-10-26 9:39 ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
2023-10-27 18:46 ` tip-bot2 for Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lebtcjnr.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=hdegoede@redhat.com \
--cc=hpa@linux.intel.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox