From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory Fong Subject: Re: [PATCH 2/7] gpio: brcmstb: release the bgpio lock during irq handlers Date: Tue, 3 Oct 2017 18:55:51 -0700 Message-ID: References: <20170930034057.15166-1-opendmb@gmail.com> <20170930034057.15166-3-opendmb@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from mail-wr0-f170.google.com ([209.85.128.170]:48793 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbdJDB4Y (ORCPT ); Tue, 3 Oct 2017 21:56:24 -0400 In-Reply-To: <20170930034057.15166-3-opendmb@gmail.com> Sender: linux-gpio-owner@vger.kernel.org List-Id: linux-gpio@vger.kernel.org To: Doug Berger Cc: Linus Walleij , Brian Norris , Florian Fainelli , bcm-kernel-feedback-list , linux-gpio@vger.kernel.org, "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Hi Doug, On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote: > The basic memory-mapped GPIO controller lock must be released > before calling the registered GPIO interrupt handlers to allow > the interrupt handlers to access the hardware. Otherwise, the > hardware accesses will deadlock when they attempt to grab the > lock. I was having some trouble understanding exactly what the problem was here, but I think I see it now. Since this locks the entire bank, where some GPIOs might be set as inputs and some as inputs (and interrupt sources), then an interrupt on a GPIO that is supposed to set another GPIO in the bank would result in deadlock. Is that correct? If so, please update the commit message to make that clear, and nice fix. If not that, it would be nice to know what scenario can cause a problem. Thanks, Gregory From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbdJDB4Z (ORCPT ); Tue, 3 Oct 2017 21:56:25 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:48793 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbdJDB4Y (ORCPT ); Tue, 3 Oct 2017 21:56:24 -0400 X-Google-Smtp-Source: AOwi7QCIRHjuXbrTzqCHmVyNCT2i6HWzmqjWAruTlTRzv1cGtNa2U/RRiGmu5vWHtTjRos02zpTzXs5xdpM8AYwn65Q= MIME-Version: 1.0 In-Reply-To: <20170930034057.15166-3-opendmb@gmail.com> References: <20170930034057.15166-1-opendmb@gmail.com> <20170930034057.15166-3-opendmb@gmail.com> From: Gregory Fong Date: Tue, 3 Oct 2017 18:55:51 -0700 Message-ID: Subject: Re: [PATCH 2/7] gpio: brcmstb: release the bgpio lock during irq handlers To: Doug Berger Cc: Linus Walleij , Brian Norris , Florian Fainelli , bcm-kernel-feedback-list , linux-gpio@vger.kernel.org, "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Doug, On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote: > The basic memory-mapped GPIO controller lock must be released > before calling the registered GPIO interrupt handlers to allow > the interrupt handlers to access the hardware. Otherwise, the > hardware accesses will deadlock when they attempt to grab the > lock. I was having some trouble understanding exactly what the problem was here, but I think I see it now. Since this locks the entire bank, where some GPIOs might be set as inputs and some as inputs (and interrupt sources), then an interrupt on a GPIO that is supposed to set another GPIO in the bank would result in deadlock. Is that correct? If so, please update the commit message to make that clear, and nice fix. If not that, it would be nice to know what scenario can cause a problem. Thanks, Gregory From mboxrd@z Thu Jan 1 00:00:00 1970 From: gregory.0xf0@gmail.com (Gregory Fong) Date: Tue, 3 Oct 2017 18:55:51 -0700 Subject: [PATCH 2/7] gpio: brcmstb: release the bgpio lock during irq handlers In-Reply-To: <20170930034057.15166-3-opendmb@gmail.com> References: <20170930034057.15166-1-opendmb@gmail.com> <20170930034057.15166-3-opendmb@gmail.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Doug, On Fri, Sep 29, 2017 at 8:40 PM, Doug Berger wrote: > The basic memory-mapped GPIO controller lock must be released > before calling the registered GPIO interrupt handlers to allow > the interrupt handlers to access the hardware. Otherwise, the > hardware accesses will deadlock when they attempt to grab the > lock. I was having some trouble understanding exactly what the problem was here, but I think I see it now. Since this locks the entire bank, where some GPIOs might be set as inputs and some as inputs (and interrupt sources), then an interrupt on a GPIO that is supposed to set another GPIO in the bank would result in deadlock. Is that correct? If so, please update the commit message to make that clear, and nice fix. If not that, it would be nice to know what scenario can cause a problem. Thanks, Gregory