From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D64E7C07E95 for ; Mon, 19 Jul 2021 17:29:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B2F8D610F7 for ; Mon, 19 Jul 2021 17:29:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349485AbhGSQsS (ORCPT ); Mon, 19 Jul 2021 12:48:18 -0400 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.53]:34755 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349697AbhGSQqH (ORCPT ); Mon, 19 Jul 2021 12:46:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1626715597; s=strato-dkim-0002; d=gerhold.net; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date:Cc:Date: From:Subject:Sender; bh=JSDTqVTfXpY/nkps/4WQBQ4jmhTTXlWkA4xD144AOWs=; b=VzhonegltXxBQblRm+I2i3+wdNeJ59FCjpOXH5aNtm7V6tWkDT6Vowdxs0RcETQYkH qKJ7dQxHR5dsi+lxnxYSN1K7ftAe+QbWn0/HqXyqrw+9lZAInuyhR4CcMJbuDG0+VJsf /9tHo5sLO2WhF1L1lkOeov9AXODw7nkDeM0N9P6E4hN+S/Xth/nP4QX1Ba+N2voPYbmQ ez4JlhBXGTvvjeVYAjhfwMzLEgZy2JzdzyAgky+cQLY2ji+9aG7oBXedr2QXJsk5qI9J OXwx1P/oYAp3sTG9bWmN/fVaUDYgBvU+KISM70Xe743zKauK/IU1LpdyiODbkhRAhC0B t88Q== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P3gBZUipdd93FF5ZZvYFPugejmSTVR2nRPhVOQ/OcYgojyw4j34+u26zEodhPgRDZ8j4IczAa4o=" X-RZG-CLASS-ID: mo00 Received: from gerhold.net by smtp.strato.de (RZmta 47.28.1 DYNA|AUTH) with ESMTPSA id g02a44x6JHQa5o9 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 19 Jul 2021 19:26:36 +0200 (CEST) Date: Mon, 19 Jul 2021 19:26:28 +0200 From: Stephan Gerhold To: Andy Shevchenko Cc: Linus Walleij , Jonathan Cameron , Lars-Peter Clausen , Rob Herring , linux-iio , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Hans de Goede , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS , Hans de Goede , Andy Shevchenko ," <~postmarketos/upstreaming@lists.sr.ht>, Nikita Travkin Subject: Re: [PATCH 3/4] iio: accel: bmc150: Make it possible to configure INT2 instead of INT1 Message-ID: References: <20210719112156.27087-1-stephan@gerhold.net> <20210719112156.27087-4-stephan@gerhold.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, Jul 19, 2021 at 07:19:05PM +0300, Andy Shevchenko wrote: > On Mon, Jul 19, 2021 at 6:11 PM Stephan Gerhold wrote: > > On Mon, Jul 19, 2021 at 06:01:01PM +0300, Andy Shevchenko wrote: > > > On Mon, Jul 19, 2021 at 5:07 PM Linus Walleij wrote: > > > > On Mon, Jul 19, 2021 at 1:26 PM Stephan Gerhold wrote: > > ... > > > > > > #include > > > > > +#include > > > > (...) > > > > > + irq_info = bmc150_accel_interrupts_int1; > > > > > + if (irq == of_irq_get_byname(dev->of_node, "INT2")) > > > > > + irq_info = bmc150_accel_interrupts_int2; > > > > > > > > This looks a bit DT-specific, but I don't see that ACPI has > > > > named IRQs so I don't know what to do about it either. > > > > > > Yeah, we only have so far the (de facto) established way of naming > > > GPIO based IRQs, and not IOxAPIC ones. > > > > > > > What does platform_get_irq_byname() do on ACPI systems? > > > > > > See above. > > > > > > > If there is no obvious fix I would leave it like this until the > > > > first ACPI used needing this comes along, but I think maybe > > > > Andy has suggestions. > > > > > > The platform_get_irq_byname() should do something similar that has > > > been done in platform_get_irq() WRT ACPI. > > > Here for sure the platform_get_irq_byname() or its optional variant > > > should be used. > > > > I don't think there is a platform device here, we only have the > > i2c_client or spi_device. That's why I didn't use > > platform_get_irq_byname(). :) > > > > Is there something equivalent for I2C/SPI drivers? > > Not yet. You probably need to supply some code there to allow > multi-IRQ devices (in resource provider agnostic way). > > You need to provide fwnode_get_irq_byname() to be similar with > https://elixir.bootlin.com/linux/latest/source/drivers/base/property.c#L1010 > > Then use it in the drivers. > > And/or integrate into frameworks somehow (something in between the > lines: https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-core-base.c#L461). > Well, I don't think anyone has an ACPI use case for this right now so it's probably better if this is done by someone who actually needs this and can test it somewhere. :) I actually just "copied" this approach from some other IIO drivers where this is done similarly (and additionally checked the source code to make sure this won't break anything for ACPI platforms). Stephan