Received: by 10.213.65.68 with SMTP id h4csp67549imn; Fri, 30 Mar 2018 14:27:53 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/Iaqmp4MNthiid9Q4GWT/Zv+GzAVt6+Xd/pdfV+qvbics+nSDIgWZ4vdwl2PTMQxZ1gZY4 X-Received: by 2002:a17:902:6a81:: with SMTP id n1-v6mr612725plk.342.1522445273543; Fri, 30 Mar 2018 14:27:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522445273; cv=none; d=google.com; s=arc-20160816; b=uoX1YD1VQO7JTDqcRpS3pyRxcQzypvg6EPStV9DPmKV+ybUWq9QAYdL6PHmmfUTV/V 7TW6MnVeYg3WAvmYpTKd0kivq7CtFgnK1orJqQ1brWfUwGEl2SkfFakAIuoKucgZ5j8y Ynnti60bM7hE84Rkngz/A7+m/um8EfrbT1hOkX17QiuqP2PuzOhV6rRUbcl9GAqPibGn JtqRyfvOhgHgHEZFbsyuBMJupOLIP+Lt3FvMzQ0hRN8hYQybc+In1a05PeebRXgRTj7o Uu0GKuVQDoEFJCttvgrhj52ZIWM5evLFwTo/Zfm2HdimUg4id0O3xi8mE4TP8VGelUEj SuwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ZSaLkEsfTVbMeo9swlYbKGvB+CkV+LkzxuNKcoIyvkk=; b=MAd8nrKehalEf8/8Q2tbCC+VNv5EwF0KLCbNt3XStJjR18TTLVlA7n8hrQJun3kGC8 8Sj3CPCNt+MPhirfOBufCMtjDyU8kzFUcZjX9sGNRrxiZ1Up0gu+NAL1/dE6A3dmCBg0 6AmP2f4rBQKjQnqheWCHXo6SUzG442HEuXaKBsEh2q55vy96GNVy3pHYLhxG35n4gMiF nwIqhTwx2GQNX84TmGQF+clRmo+E4HivZ80m9yMSp3dvAeNSxjyb+66WQ/ElGM1F1IK5 8NNqh6l0gWM8VoytHXxAkDnW9RK5NYxlzGnK7Vo+HGWNSfUtZd3tR/ujl8neeDHlacIt P1Gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GAZxpY6T; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b9-v6si9406926pla.32.2018.03.30.14.27.35; Fri, 30 Mar 2018 14:27:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GAZxpY6T; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752832AbeC3V01 (ORCPT + 99 others); Fri, 30 Mar 2018 17:26:27 -0400 Received: from mail-qt0-f179.google.com ([209.85.216.179]:37031 "EHLO mail-qt0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752571AbeC3V0Y (ORCPT ); Fri, 30 Mar 2018 17:26:24 -0400 Received: by mail-qt0-f179.google.com with SMTP id w12so10478524qti.4; Fri, 30 Mar 2018 14:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZSaLkEsfTVbMeo9swlYbKGvB+CkV+LkzxuNKcoIyvkk=; b=GAZxpY6T5tFg1cK0QSGexkayjwVl+iZcOCEDcsUYGGFe618PP/bN2JOyygYixavvpJ nYfj3HEGDqmw2lApMtWHZbKAETUqamqi2lPU06yFvpB8Oa6aGEQu1jOfGquJDgjaQlvj PwZQvzTNQZ6zLNNQphpKDmMCVQLqwcbr4rJb0WL8Cxzbb7Wif8g7dCz4v+ONbcM71uE4 iyT4ltkkuoni2mAQniuDYSCgnFapJcUje2IQBCO7+pJTQ03PKm1mipmPCcAdsl3z2c72 1JuO38onOnyIxY2Q1XBu0nhYBmFUHp6BFTa6xYVjATa9PEHvepKAEejVqnFP2uEW4x+K FS2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZSaLkEsfTVbMeo9swlYbKGvB+CkV+LkzxuNKcoIyvkk=; b=iFoOOZl5QOYmnStMs2hC5+9NKHyjE4W+fZW0UVIFy1lBZR7Cd6Vv1156QB/TpptY4X HER1bmazHhnQvGZaVtEPXBrOnlGLvpGkIutTibfqxl8hf5UYWUSm1VF7vw0aR6A+oZtE 6LI9NH78R2s2HNX/x9MsG2OeojtqVdcCGVYmXJBO9JvREwIYZVCU8xQq2fUIw2VsfdGA 1nVxF+xzN8g+RZSxXtQQY1f7sD62mE5PTYpzSMOi8wXulyuQlSRXT68gVvm5iVS6BsvO fX9q6b40F3ybuRl8pt9xY39ZMsleN+Vcd2qWKqfTd6gayNfGmqxQmWI89KY73MoUmMtR COwA== X-Gm-Message-State: ALQs6tDEfgRjXbG/C6Xf+HvzB2PvzisaQ/y/xB13KD4DhbnoPfIqdX4S GJazHn2WMiAuiW5vhGffZoMz465Rz+obPRZVEoc= X-Received: by 10.200.25.20 with SMTP id t20mr920444qtj.187.1522445183967; Fri, 30 Mar 2018 14:26:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.74 with HTTP; Fri, 30 Mar 2018 14:26:23 -0700 (PDT) In-Reply-To: <1522246950-9110-1-git-send-email-phil.edworthy@renesas.com> References: <1522246950-9110-1-git-send-email-phil.edworthy@renesas.com> From: Andy Shevchenko Date: Sat, 31 Mar 2018 00:26:23 +0300 Message-ID: Subject: Re: [PATCH] gpio: dwapb: Add support for 32 interrupts To: Phil Edworthy Cc: Hoan Tran , Linus Walleij , Rob Herring , Mark Rutland , Michel Pollet , "open list:GPIO SUBSYSTEM" , devicetree , Linux-Renesas , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 28, 2018 at 5:22 PM, Phil Edworthy wrote: > The DesignWare GPIO IP can be configured for either 1 or 32 interrupts, 1 to 32, or just a choice between two? > but the driver currently only supports 1 interrupt. See the DesignWare > DW_apb_gpio Databook description of the 'GPIO_INTR_IO' parameter. Will see after holiday and perhaps make more comments. Here is just a brief review. > +- interrupts : The interrupts to the parent controller raised when GPIOs > + generate the interrupts. If the controller provides one combined interrupt > + for all GPIOs, specify a single interrupt. If the controller provides one > + interrupt for each GPIO, provide a list of interrupts that correspond to each > + of the GPIO pins. When specifying multiple interrupts, if any of the GPIOs are > + not connected to an interrupt, use the interrupt-mask property. > +- interrupt-mask : a 32-bit bit mask that specifies which interrupts in the list > + of interrupts is valid, bit is 1 for a valid irq. So, but why one will need that in practice? GPIO driver usually provides a pin based IRQ chip which maps each pin to the corresponding offset inside specific IRQ domain. > + struct device_node *np = to_of_node(fwnode); > + u32 irq_mask = 0xFFFFFFFF; Why? Shouldn't it be dependent to the amount of actual pins / ports? Intel Quark has only 8 AFAIR. > + int j; > + > + /* Optional irq mask */ > + fwnode_property_read_u32(fwnode, "interrupt-mask", &irq_mask); > + > + /* > + * The IP has configuration options to allow a single > + * combined interrupt or one per gpio. If one per gpio, > + * some might not be used. > + */ > + for (j = 0; j < pp->ngpio; j++) { > + if (irq_mask & BIT(j)) { for_each_set_bit() is in kernel for ages! > + pp->irq[j] = irq_of_parse_and_map(np, j); > + if (pp->irq[j]) > + pp->has_irq = true; > + } > + } So, on the first glance the patch looks either superfluous or taking wrong approach. Please, elaborate more why it's done in this way and what the case for all this in practice. -- With Best Regards, Andy Shevchenko