Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1623614
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC] Fix shared irq trigger-flags conflict when old irqaction uses IRQF_TRIGGER_NONE |
| Date | 2017-04-14 11:40 +0200 |
| Message-ID | <tw5RU-7Pb-37@gated-at.bofh.it> (permalink) |
| References | <tura9-7lQ-3@gated-at.bofh.it> <tuEAp-7Nw-5@gated-at.bofh.it> <tuFmO-8iD-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, 10 Apr 2017, Hans de Goede wrote:
> Where the new_action trigger_mask gets filled with the triger_mask
> from the irq_data, which is a further hint that looking at
> irqd_get_trigger_type(&desc->irq_data) rather then at
> (old->flags IRQF_TRIGGER_MASK) is probably the right fix.
>
> Note btw that 4b357daed698 is (part of) what is breaking things for
> my use-case, I request the irq with IRQF_TRIGGER_NONE but
> 4b357daed698 modifies that before comparing the new trigger flags
> to the old.
The issue here is, that at the time of the first setup_irq() the trigger
type in irq_data is NONE. As a consequence the following is a NOOP:
if (!new->trigger)
new->flags |= get_type(irqdata);
Now the irq is started up for the first time and then the actual trigger
type gets established, but that's to late to fix up new->flags.
So yes, we should change the logic for the shared case to:
if (old) {
oldtype = get_type(irqdata);
if (oldtype != newtype)
goto mismatch;
That should cover all cases.
Thanks,
tglx
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [RFC] Fix shared irq trigger-flags conflict when old irqaction uses IRQF_TRIGGER_NONE Thomas Gleixner <tglx@linutronix.de> - 2017-04-14 11:40 +0200
csiph-web