From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756260AbdE0LMn (ORCPT ); Sat, 27 May 2017 07:12:43 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:43995 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752602AbdE0LMm (ORCPT ); Sat, 27 May 2017 07:12:42 -0400 Date: Sat, 27 May 2017 13:12:38 +0200 (CEST) From: Thomas Gleixner To: Jeffy Chen cc: linux-kernel@vger.kernel.org, briannorris@chromium.org, dianders@chromium.org, tfiga@chromium.org Subject: Re: [PATCH v3] genirq: Check irq disabled & masked states in irq_shutdown In-Reply-To: <1495879508-17491-1-git-send-email-jeffy.chen@rock-chips.com> Message-ID: References: <1495879508-17491-1-git-send-email-jeffy.chen@rock-chips.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 27 May 2017, Jeffy Chen wrote: > If a irq is already disabled, irq_shutdown may try to disable it again, > for example: > devm_request_irq->irq_startup->irq_enable > disable_irq <-- disabled > devm_free_irq->irq_shutdown <-- disable it again > > This would confuse some chips which require balanced irq enable and > disable, for example pinctrl-rockchip & pinctrl-nomadik. "would confuse" is an interesting technical term. Can you please start to explain things in coherent sentences so people who do not have detailed knowledge of the problem at hand can understand it? > Add a state check before calling irq_disable to prevent that. So you analyzed in half an hour that all of this is correct and fixes all possible imbalances, right? Really impressive! You just forgot to mention this in the changelog. > v2: Rewrite commit message. > v3: Rewrite commit message and not skip irq_shutdown. This does not belong into the changelog and having that information twice is more than pointless. Before you send yet another version of this within 5 minutes, can you please sit down and analyze all the possible imbalance scenarios? I'm not going to apply hastiliy cobbled together workarounds which "fix" just half of the problem space. This is not random driver code which breaks ONE type of machine. This is core code which has the potential to break ALL machines out there in one go. Either you come up with a properly analyzed solution which addresses all possible imbalanced invocations or you have to wait until I find some time to look at it myself. Thanks, tglx