Port-amd64 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] Add intr_mask() / intr_unmask() interface to mask / unmask individual interrupt sources
Anyone? Bueller?
> On Aug 7, 2019, at 10:41 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
>
> Folks --
>
> A patch I need reviewed by x86 interrupt handling experts. It adds two new routines:
>
> void intr_mask(void *ih);
> void intr_unmask(void *ih);
>
> That mask and unmask, respectively, individual interrupt sources. The "ih" argument is the interrupt cookie that's returned by intr_establish().
>
> There are some corresponding changes to the ACPI interrupt functions that I haven't included here, but suffice to say they're basic wrappers.
>
> These changes are needed in order to be able to defer processing of a hard interrupt to a softint in some circumstances, specifically in cases where it's not actually safe to access the interrupting device's registers while in interrupt context. Real world example: ihidev (hid-over-i2c driver). That driver currently does i2c access from the hardware interrupt, but it plays some unsavory tricks in order to do so, and it can't work in all cases as-written. Unfortunately, the hid-over-i2c spec specifies a level-triggered interrupt, hence the need to be able to mask it off after scheduling a softint. The interrupt can then be unmasked after processing all outstanding data from the input device.
>
> Unfortunately, I don't have a uhidev device I can test this against directly. I know bouyer@ does, and I am hoping he can test the larger set of changes I'm working on. I have tested these patches at least in the sense that the system boots multi-user ... i.e. I didn't break anything :-)
>
> I would appreciate review of these changes by someone who is very familiar with the x86 interrupt handling code. I am pretty sure I got this right, but it's a critical section of code so I want to be sure. The interrupt vector changes essentially check the "mask count" of the intrsource and treat it as an interrupt masked by splXXX() in two places:
>
> 1- Upon entry to an interrupt vector (either by the "interrupted" path or by the "resume" path).
>
> 2- Upon return from invoking all of the handlers for an intrsource ... because the hard interrupt handler will be the thing requesting the interrupt to be masked, we check here so we can void re-enabling the source, thus avoiding an extra interrupt just to mark it as pending.
>
> Note that it's important for a masked interrupt source to always be marked as "pending" so that it can be reliably serviced again when unmasked.
>
> Diff attached. Please let me know if it looks OK or if you have any questions.
>
> Thanks!
>
> <x86-intr-diffs.txt>
> -- thorpej
>
-- thorpej
Home |
Main Index |
Thread Index |
Old Index