From patchwork Tue Jul 5 14:52:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 9214543 X-Patchwork-Delegate: geert@linux-m68k.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 68E8860752 for ; Tue, 5 Jul 2016 14:52:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5A2AF25749 for ; Tue, 5 Jul 2016 14:52:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4E97F25D99; Tue, 5 Jul 2016 14:52:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BA61425749 for ; Tue, 5 Jul 2016 14:52:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755093AbcGEOwo (ORCPT ); Tue, 5 Jul 2016 10:52:44 -0400 Received: from mail-oi0-f48.google.com ([209.85.218.48]:34473 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754781AbcGEOwn (ORCPT ); Tue, 5 Jul 2016 10:52:43 -0400 Received: by mail-oi0-f48.google.com with SMTP id s66so232120129oif.1 for ; Tue, 05 Jul 2016 07:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Qv/VCOBx9vpMnlWFumZHq0QdniA3AwTnO0Km1CW5eM=; b=Cx26+Gr1BeCVTbtM8/++44XfGJdzE6sUOZNtBpK9kbrhndcgRAWeywKxZyxV2avP5I D9kGx7cGsqBZnAqWhnHIsg2oNdiXWy7ZWd0hnUZLzkUbISLhfRQDAISzjKPKqmmidt+O aD8r0tm92B92QyWyzDWYrFvkwK7zX6qv5a1Xk= 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:from:date :message-id:subject:to:cc; bh=/Qv/VCOBx9vpMnlWFumZHq0QdniA3AwTnO0Km1CW5eM=; b=E0LfJkNmFazMkChDtxqidbadDrp9JRjbw4wqcu57jgbxvwZtDpYAcZuVVlcZDnzUhP 08Jgfj1krhqs1ukYt+ISUi283S+Rgr24SpfdjrU+5inkzmRjTkR64IaFO9Rwly2xExmv Sq5Dz0IIU9MdSQCqFbAarRdNk2d5Wd6eNRihzbcHuqTW4wASDC+vqynOoNxsJdgF8Rhz MNnp//+QtZUHG1y1y4x95oakAoA+WZZHcRYYF+UKZB7Uee5LtOZ46e1QygHllO9+1yjM di2W2eC5ZmTzraea8zve+MW20CbsqQwWUv6HFFHRBhAKTUzUJ/HEiF4U3PcBVOmq7Dg5 0P0w== X-Gm-Message-State: ALyK8tL6P87sFlMxxxlnErMM2Z1WJUfxebQElDlayP3OfY8sRXNeb4yzq5VI71D6luxJZhFprfGshFk4zkQEVwEO X-Received: by 10.157.37.119 with SMTP id j52mr2103502otd.115.1467730361882; Tue, 05 Jul 2016 07:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.143.41 with HTTP; Tue, 5 Jul 2016 07:52:41 -0700 (PDT) In-Reply-To: References: <1466630758-26231-1-git-send-email-linus.walleij@linaro.org> From: Linus Walleij Date: Tue, 5 Jul 2016 16:52:41 +0200 Message-ID: Subject: Re: [PATCH v2] gpio: convince line to become input in irq helper To: Geert Uytterhoeven Cc: "linux-gpio@vger.kernel.org" , Alexandre Courbot , =?UTF-8?Q?Bj=C3=B6rn_Andersson?= , Linux-Renesas Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I sent a patch for the direction setter to be more careful, but it's no silver bullet for strange semantics. On Tue, Jul 5, 2016 at 12:07 PM, Geert Uytterhoeven wrote: > [1] gpio_rcar e6052000.gpio: sense irq = 11, type = 8 > ravb e6800000.ethernet eth0: Base address at 0xe6800000, > 2e:09:0a:00:83:1e, IRQ 131. > ... > [2] gpiochip_irq_reqres: gpiochip e6052000.gpio > [3] gpio_rcar e6052000.gpio: gpio_rcar_direction_input: 11 > [4] gpiochip_irq_reqres: desc->flags = 0x0 (...) > This configures the GPIO for plain input mode, cfr. [3] above, basically > undoing the configuration from [1]. Hence interrupts no longer come through, > and Ethernet fails. The driver is a bit fragile in that it relies on a certain call semantic, I guess it is not a widespread problem so we should be able to make a local fix if necessary. The .set_direction() call should set the direction. Why is it turning off interrupts as a side effect? What happens if you apply this, making the .request() function handle the pin setup and .set_direction() really just setting the direction? */ @@ -234,14 +247,8 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip, /* Select "General Input/Output Mode" in IOINTSEL */ gpio_rcar_modify_bit(p, IOINTSEL, gpio, false); - /* Select Input Mode or Output Mode in INOUTSEL */ - gpio_rcar_modify_bit(p, INOUTSEL, gpio, output); - spin_unlock_irqrestore(&p->lock, flags); -} -static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset) -{ return pinctrl_request_gpio(chip->base + offset); } .request() is always called before .set_direction() when issuing gpiod_get() anyways, so the order required according to the comment will be satisfied when the GPIO is first requested, but if we're just using the interrupt, we still will be able to set the direction right. Yours, Linus Walleij diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c index 681c93fb9e70..68fb0147caf4 100644 --- a/drivers/gpio/gpio-rcar.c +++ b/drivers/gpio/gpio-rcar.c @@ -221,7 +221,20 @@ static void gpio_rcar_config_general_input_output_mode(struct gpio_chip *chip, struct gpio_rcar_priv *p = gpiochip_get_data(chip); unsigned long flags; - /* follow steps in the GPIO documentation for + spin_lock_irqsave(&p->lock, flags); + + /* Select Input Mode or Output Mode in INOUTSEL */ + gpio_rcar_modify_bit(p, INOUTSEL, gpio, output); + + spin_unlock_irqrestore(&p->lock, flags); +} + +static int gpio_rcar_request(struct gpio_chip *chip, unsigned offset) +{ + struct gpio_rcar_priv *p = gpiochip_get_data(chip); + + /* + * follow steps in the GPIO documentation for * "Setting General Output Mode" and * "Setting General Input Mode"