From patchwork Fri Apr 1 08:43:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 8721771 Return-Path: X-Original-To: patchwork-linux-input@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 651E8C0553 for ; Fri, 1 Apr 2016 08:43:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 81F492039E for ; Fri, 1 Apr 2016 08:43:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 60C4020390 for ; Fri, 1 Apr 2016 08:43:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753305AbcDAInd (ORCPT ); Fri, 1 Apr 2016 04:43:33 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:33292 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753292AbcDAInb (ORCPT ); Fri, 1 Apr 2016 04:43:31 -0400 Received: by mail-oi0-f47.google.com with SMTP id d205so96548582oia.0 for ; Fri, 01 Apr 2016 01:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iqA8q8W3JD4Ipr46nKBGIrBRYbuMIMxwR/+emZr/M8s=; b=GrcsC0V7EcPb+DOJa7+B+FvRNzWFgyIBS2a6TblothtUi6TZB3LNjBZ/AnKWaWk6Di VKndyG7y/iv2M137DytVZHcrfGOyuDGOdZpkwjfkqAaJs5Pxjcblqqhg4+MAmi4/ka2O k6xdu1Kel19NK6sw5zbBU+V5hl45qDsbEijBU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iqA8q8W3JD4Ipr46nKBGIrBRYbuMIMxwR/+emZr/M8s=; b=la3T7IZnM7QRw9r64teoCUt7DuGdieY9XuRVvbq8OlX2U9EyVgNL1JL3tT5o4we3fI EommRIWkWQO0szZlbQbEKmi8WENS10QOXwU+I294yXVOHBcqh4ei70ca3NItsbcBX1ev 1o7ZPj1KHzGdXnGuz2wnkBGKgWSf/YybIq4/lWszjYxCWr0PkvxN2cJ4F4a8l6SCoGog PzXrkvT56BMjoNGpWdJZbbEmOZYQh94cI5L+SbmvoezOKO7jjfg2y2dFtK6ZCJ/oRE6m NsRi//UkcUC6UWMAk9T/jNZmNPCmVkfr7vPQTrydo0QTlvKRLCC8T0vMlA4qPQA3Gv1B eR6A== X-Gm-Message-State: AD7BkJLlcNHxYi3xadXqH3vC8YRjp363qMobOkOlHyaxdsm/3B9zSv2tqtArLyC6X/OaXW0s7o9wQrI/h45C57NF MIME-Version: 1.0 X-Received: by 10.157.63.116 with SMTP id m107mr1896565otc.115.1459500210548; Fri, 01 Apr 2016 01:43:30 -0700 (PDT) Received: by 10.182.55.105 with HTTP; Fri, 1 Apr 2016 01:43:30 -0700 (PDT) In-Reply-To: <44236018.b6N0xPzKYW@ws-stein> References: <44236018.b6N0xPzKYW@ws-stein> Date: Fri, 1 Apr 2016 10:43:30 +0200 Message-ID: Subject: Re: gpio irqchip initialization race From: Linus Walleij To: Alexander Stein , Dmitry Torokhov Cc: "linux-gpio@vger.kernel.org" , Alexandre Courbot , Linux Input Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Apr 1, 2016 at 10:28 AM, Alexander Stein wrote: > I suspect this depends on the time when gpio-keys is being probed. It will not > be probed (or actually deferred) before mcp23s08_probe_one calls > gpiochip_add_data as the parent GPIo controller to buttons is not present yet. > I guess those error messages raise when gpio-keys is probed after > gpiochip_add_data but before gpiochip_irqchip_add or > gpiochip_set_chained_irqchip (in mcp23s08_irq_setup). > > The comment to _gpiochip_irqchip_add states the gpiochip has to be registered > when calling. So to me this opens a rather small window where childs to > gpiochip can be probed (parent is registered) but registering an interrupt > will fail as the parent IRQ setup has not finished yet. > Any suggestions how to fix that? If that is what is happening it is indeed a very annoying race condition. Strange we haven't seen it before! So the problem doesn't exist when just using the gpiolib API or the irqchip side independently, as we have been careful to make sure that at least in modern drivers, these two are orthogonal. I think the problem is that gpio-keys is calling gpio_to_irq(), and at that point between gpiochip_add_data() but before gpiochip_irqchip_add() it gets a bogus IRQ when it should be getting -EPROBE_DEFER. I think we need to make sure that for drivers using gpiolib_irqchip_add() -EPROBE_DEFER is returned for gpio[d]_to_irq() for this interrim period. What happens if you just apply this oneliner? Yours, Linus Walleij --- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index b747c76fd2b1..838643d2d976 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -2004,7 +2004,7 @@ int gpiod_to_irq(const struct gpio_desc *desc) VALIDATE_DESC(desc); chip = desc->gdev->chip; offset = gpio_chip_hwgpio(desc); - return chip->to_irq ? chip->to_irq(chip, offset) : -ENXIO; + return chip->to_irq ? chip->to_irq(chip, offset) : -EPROBE_DEFER; } EXPORT_SYMBOL_GPL(gpiod_to_irq);