From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751240AbdE3XUE (ORCPT ); Tue, 30 May 2017 19:20:04 -0400 Received: from mail-pf0-f172.google.com ([209.85.192.172]:34691 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750825AbdE3XUD (ORCPT ); Tue, 30 May 2017 19:20:03 -0400 Date: Tue, 30 May 2017 16:20:00 -0700 From: Brian Norris To: Thomas Gleixner Cc: jeffy , LKML , dianders@chromium.org, tfiga@chromium.org, Johannes Berg Subject: Re: [PATCH] genirq: Check irq disabled & masked states in irq_shutdown Message-ID: <20170530231956.GA25960@google.com> References: <1495804658-12410-1-git-send-email-jeffy.chen@rock-chips.com> <592905F7.4010803@rock-chips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, To address a tangent brought up here: On Sat, May 27, 2017 at 10:16:37AM +0200, Thomas Gleixner wrote: > On Sat, 27 May 2017, jeffy wrote: > > for example when a driver(drivers/net/wireless/marvell/mwifiex/main.c) try to > > do these: > > > > devm_request_irq->irq_startup->irq_enable > > disable_irq <-- disabled and masked > > devm_free_irq->irq_shutdown <-- disable it again > > This driver is broken as hell. No argument on the general statement :) > It requests the interrupt _BEFORE_ the whole > thing is initialized. If there is a pending interrupt on that line, it will > explode nicely before it is able to disable the irq. But that's a different > problem. For that particular interrupt, it's mostly an informational interrupt regarding wakeups. We don't do anything that could blow up there, except report a (spurious) wakeup event. (And this spurious wakeup event only occurs because the Wifi firmware may toggle its "wake" pin even when the system is already awake. A weird behavior...) So yes, the pattern isn't great, but no, it's not going to blow up, AFAIK. However, if you were to look at the same driver's .../mwifiex/pcie.c, you would see a similar problem, and you *would* be right if you claimed that things could blow up badly there! mwifiex_pcie_request_irq() is called much too early, and if an interrupt gets queued up at the wrong time, we won't handle it very nicely. Anyway, I just thought I'd mention it, in case someone else following this thread is curious. Coincidentally, I'm already working on patching this on linux-wireless@. Side note: for issues like the first problem above, I wonder why there isn't a flag that once could pass to request_irq() that suggests the IRQ should be initially disabled? I know this wouldn't work for shared interrupts (but request_irq() could reject that combination, no?), but it seems like there are plenty of cases where it might be useful. Some devices simply don't have a device-level interrupt mask, and always expect to have a dedicated interrupt. With the status quo, a driver for such a device has to defer their request_irq() until sometimes-inconvient times [1], or else accept some subpar behavior (see above "spurious wakeup reporting"). Regards, Brian [1] Note that, for one, request_irq() can fail, whereas enable_irq() cannot.