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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1E75C433EF for ; Mon, 6 Dec 2021 19:13:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347367AbhLFTRB (ORCPT ); Mon, 6 Dec 2021 14:17:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348323AbhLFTRB (ORCPT ); Mon, 6 Dec 2021 14:17:01 -0500 Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6626BC061746 for ; Mon, 6 Dec 2021 11:13:32 -0800 (PST) Received: from [81.101.6.87] (port=48014 helo=jic23-huawei) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1muJQT-0002fT-Ll; Mon, 06 Dec 2021 19:13:30 +0000 Date: Mon, 6 Dec 2021 19:18:29 +0000 From: Jonathan Cameron To: Andy Shevchenko Cc: linux-iio , Alexandru Ardelean , Lars-Peter Clausen , Jonathan Cameron Subject: Re: [PATCH v3 3/5] iio: accel: mma9551: Add support to get irqs directly from fwnode Message-ID: <20211206191804.443def0b@jic23-huawei> In-Reply-To: References: <20211205200250.2840902-1-jic23@kernel.org> <20211205200250.2840902-4-jic23@kernel.org> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BlackCat-Spam-Score: 4 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On Sun, 5 Dec 2021 22:39:07 +0200 Andy Shevchenko wrote: > On Sun, Dec 5, 2021 at 9:57 PM Jonathan Cameron wrote: > > > > From: Jonathan Cameron > > > > Note the interrupt type should be specified by firmware, not the driver > > so that is also dropped. > > > > Drop previous gpio based retrieval method. Whilst in theory this > > might cause problems with direction if anyone is using ACPI GioIo(). > > GpioIo() My proofreading fails me again... > > > As Andy described in v1, such a situation would typically reflect > > a pin that is actually used in both directions (not true here) > > or missdesigned ACPI tables. > > ... > > > - gpio = devm_gpiod_get_index(dev, NULL, i, GPIOD_IN); > > - if (IS_ERR(gpio)) { > > - dev_err(dev, "acpi gpio get index failed\n"); > > - return PTR_ERR(gpio); > > - } > > - > > - ret = gpiod_to_irq(gpio); > > - if (ret < 0) > > > + ret = fwnode_irq_get(dev_fwnode(dev), i); > > + if (ret) > > return ret; > > I don't remember why we decided that this gonna work, because > fwnode_irq_get() is not an equivalent to the above, more precisely in > ACPI case it only covers the GSIs (Global System Interrupts) which in > such case may or may not be GPIOs. On x86 it's usually direct IOxAPIC > ones. This isn't accessed as a GPIO, but I kind of assume someone was using it with one given this code. I think I misread what you'd written in reply to v1. Thanks for the explanation. > > So, this conversion would probably make it impossible to use this > device in the ACPI case. oops :) > > See also this discussion: > https://lore.kernel.org/lkml/20211109200840.135019-1-puranjay12@gmail.com/T/#u > I'd not made the connection that the non named one was also missing most of the ways it could be specified. Ah well, this will take a little while to get a test framework in place to poke at it properly. Maybe one for a bored moment over the festive season. Jonathan