-
-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add lspci
app, restructure PCI legacy interrupts (INTx) initialization
#1081
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lspci
app itself is fine. I left some comments about other PCI changes, the most significant of which is how the INTx interrupt handlers are initialized (and how it differs across architectures).
lspci
commandlspci
app, restructure PCI legacy interrupts (INTx) initialization
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I've accepted it and left a comment for a minor future improvement. Let me know your thoughts on that.
let intx_numbers = INTX_NUMBERS.lock(); | ||
intx_numbers[$num].expect("uninitialized x86 PCI INTx handler") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit funky and kinda hard to read; I think this is a good place to just include this logic in the actual body of the interrupt handler and issue an EOI directly in the body instead of returning HandlerDidNotSendEoi
.
Another thing we could do is to include the interrupt number alongside the waker
instance or alongside the INTX_DEVICES
static, in order to "ensure" those are always available.
) * INTX interrupt handler registration for PCI devices is now done lazily on both architectures. * On aarch64, the interrupt numbers are known statically. * On x86_64, we expect that the driver or module using the PCI device knows which interrupt number to use. Technically this information can be discovered through ACPI AML, but we do not yet support that because it is tedious and difficult. * Clarify PCI interrupt information functions, e.g., MSI/MSI-x support, etc. Co-authored-by: Kevin Boos <1139460+kevinaboos@users.noreply.github.com> ac5712c
(This PR depends on #1071)
This adds an
lspci
command:It takes no argument and always lists all devices.