From patchwork Mon Oct 8 16:32:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 980661 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="ggpwLzTs"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42TQrQ1sKGz9s55 for ; Tue, 9 Oct 2018 03:32:38 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726923AbeJHXow (ORCPT ); Mon, 8 Oct 2018 19:44:52 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:38029 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726810AbeJHXow (ORCPT ); Mon, 8 Oct 2018 19:44:52 -0400 Received: by mail-pg1-f195.google.com with SMTP id f8-v6so1660804pgq.5 for ; Mon, 08 Oct 2018 09:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=L7ySiBOV6v4YVbOgXXN8Qe8bELIY9QXgwcfs0zDgPag=; b=ggpwLzTsf7tf8vXPmSIRSmdp1L7WtOA4hALlTi6klcSKIt1e+4cjf0fnJrmLrDsBeg hfOg24kDOijhXK/xD98CX0vnM5LH0RRJQpTIMzgL4FjhGpiSr1a/B62TfqQzG4VRrFGh DyyMNlNJre+hMvqfQJq6axvc9QgNdDmWRtjGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=L7ySiBOV6v4YVbOgXXN8Qe8bELIY9QXgwcfs0zDgPag=; b=q8pna4J8Ijdeh2P36uTz3oeOQ5IVH79bHS+/odDnE7thhCZWnpjuyN6wJEqP152x8D yL/g20GwoehU3WGICTujfWnw6dNv5GDn/WwzfAw+RLZUmA7w/LONP+/GIfAxS01tim3I VDh3tCrOp9T1jZSKw/MALfpJkuZy1P9+1ZllU1huq126MxlB88by++bUxmbkGQSq2Ky9 Nr/fWHJKo3qi/O5/2AkTFi+sJTM7ocvmA2a1jfFWxVZuB57jUbRGso6CkIGOZMDIy1Ho CaMnphZOp0Pmm79ttA+CcW41E4LngFJ6Nb1jC4onBetXBvOeVp6TYndjYvw8i9MVw9xN q4sg== X-Gm-Message-State: ABuFfoh9Gz+HzTLyWybIujyIpLdLPsTgVpmJ11r/rAD+k7F2YtH0ctDX wMfU0EAN3UaKOYw2so9Pt0QP3g== X-Google-Smtp-Source: ACcGV60wiZqY2GAAHuB8dVRXxVX21ZCdNKD4+f3L0+ECkVEDjM75VSrrNlXjDNbf5DbnaWLZH2ZYmg== X-Received: by 2002:a62:1095:: with SMTP id 21-v6mr25511922pfq.227.1539016339748; Mon, 08 Oct 2018 09:32:19 -0700 (PDT) Received: from smtp.gmail.com ([2620:15c:202:1:fed3:9637:a13a:6c15]) by smtp.gmail.com with ESMTPSA id 3-v6sm29832077pga.12.2018.10.08.09.32.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Oct 2018 09:32:19 -0700 (PDT) From: Stephen Boyd To: Linus Walleij Cc: linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, Evan Green , Thierry Reding , Grygorii Strashko Subject: [PATCH 2/4] gpio: Drop parent irq assignment during cascade setup Date: Mon, 8 Oct 2018 09:32:14 -0700 Message-Id: <20181008163216.97436-3-swboyd@chromium.org> X-Mailer: git-send-email 2.19.0.605.g01d371f741-goog In-Reply-To: <20181008163216.97436-1-swboyd@chromium.org> References: <20181008163216.97436-1-swboyd@chromium.org> MIME-Version: 1.0 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org We want to set the irq parent for interrupts that we're setting up to be cascaded from another interrupt controller, but we may or may not have already mapped the gpiochip irqs into the kernel's virtual irq number space at this point. If we have mapped irqs before calling here, then we've gone through gpiochip_irq_map() and called irq_set_parent() already. If we haven't mapped irqs, then the gpiochip is dynamically mapping irqs and we can rely on gpiochip_irq_map() or the gpio driver's irqdomain ops to setup the irq parent properly. Either way, setting the parent here when cascading the gpiochip doesn't make much sense because it should be done at irq mapping time. In the dynamic mapping case, this code is mapping virq 0 to some parent virq in a loop. While that's benign, let's drop this code to simplify. Cc: Evan Green Cc: Thierry Reding Cc: Grygorii Strashko Signed-off-by: Stephen Boyd --- drivers/gpio/gpiolib.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index d9d823e3761b..8fccfcf559ee 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1663,8 +1663,6 @@ static void gpiochip_set_cascaded_irqchip(struct gpio_chip *gpiochip, unsigned int parent_irq, irq_flow_handler_t parent_handler) { - unsigned int offset; - if (!gpiochip->irq.domain) { chip_err(gpiochip, "called %s before setting up irqchip\n", __func__); @@ -1688,14 +1686,6 @@ static void gpiochip_set_cascaded_irqchip(struct gpio_chip *gpiochip, gpiochip->irq.parents = &gpiochip->irq.parent_irq; gpiochip->irq.num_parents = 1; } - - /* Set the parent IRQ for all affected IRQs */ - for (offset = 0; offset < gpiochip->ngpio; offset++) { - if (!gpiochip_irqchip_irq_valid(gpiochip, offset)) - continue; - irq_set_parent(irq_find_mapping(gpiochip->irq.domain, offset), - parent_irq); - } } /**