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=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,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 97C7DC07E95 for ; Mon, 19 Jul 2021 15:11:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 844366120D for ; Mon, 19 Jul 2021 15:11:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243678AbhGSObM (ORCPT ); Mon, 19 Jul 2021 10:31:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243384AbhGSO2y (ORCPT ); Mon, 19 Jul 2021 10:28:54 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EAF4C0617A6; Mon, 19 Jul 2021 07:30:45 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id y17so19210841pgf.12; Mon, 19 Jul 2021 08:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wdrBvN6KgpslFeTTeHrxK2c0CP6V1JmbD0RP39VrpGQ=; b=T+VRamOUx2J1Ix+6/rwuqLTgyBL9wRD4OTofxsHjBp/a5DG3RzaXYQnrY3yvQvtAk8 Mf4ri6iwd36GOUfYfJPGjG1/aOEBkA8s6aDCnpNdsUF+sNRZmEasMr2YwHmETcDhV/ku fDhYS+cpIsvpClTdSkMyY62U5a+xiFhy1cdYb4jYwoSgJkPZUjFYRlfm/7NrseZOPRbD wCoY/MMrVxh0nk5cv8suVWskGgBUjc+l1smAukXmE0W0tUbI+WhLJYvPfqg/OFAp1gSV L5OC5UZh1rxjKZewDPq3iX0TvbnYeo/Y8abOfdaJkra6QHsZr+S6Kp21sV1yRI+HsT9z 3Z2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wdrBvN6KgpslFeTTeHrxK2c0CP6V1JmbD0RP39VrpGQ=; b=Hxs40XwyZQ3eAHw4fKaUeZhwf8yZrxuS6UWsYGkRObPYl5sTOwlEZycHu2KzZPIqjj cbPJI18QxnH59JfQ0dFu7H07VIj4lYV+h00rc9lYO+K7Z6vq7xjB8sdaB6XWfJHkvdFu +PZcP0AMkpMpHG4aDYyRCX6muY2CLvt2QkixBZTOXk3PQXmtUFiEc453A0rYc/EpIMkl +BqeWQiK7NnKR8rPBf+7dUCMXQSoVN0Xd+OVDqfGb8800ktTOZjDSml505CFDVxOYGFg PxnsCpeQdN67HAcoAFTipr7Ostzr94gNXnqYd7rIkmEEs99kGTBhwMtdopLCYmAemOre B9Vg== X-Gm-Message-State: AOAM532m099xPK++gMcORPS/GOvhUe+UGIjkkaeAfU+cFG+v14uNfPBi nj5tek7oWi9cVNMPXgixhwH5hjvXFIvcikWfQlQ= X-Google-Smtp-Source: ABdhPJwspJQh5QPrBysOLPL3RMxOTHGXTBgMV2d8/Ipncc8gfGsaVBWkPlWWhlLBwcRUSxFG2VBSabD8subgB5pOso0= X-Received: by 2002:a63:5a5b:: with SMTP id k27mr25929651pgm.74.1626706900991; Mon, 19 Jul 2021 08:01:40 -0700 (PDT) MIME-Version: 1.0 References: <20210719112156.27087-1-stephan@gerhold.net> <20210719112156.27087-4-stephan@gerhold.net> In-Reply-To: From: Andy Shevchenko Date: Mon, 19 Jul 2021 18:01:01 +0300 Message-ID: Subject: Re: [PATCH 3/4] iio: accel: bmc150: Make it possible to configure INT2 instead of INT1 To: Linus Walleij Cc: Stephan Gerhold , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, Jul 19, 2021 at 5:07 PM Linus Walleij wrote: > On Mon, Jul 19, 2021 at 1:26 PM Stephan Gerhold wrote: > > > Some Bosch accelerometers have two interrupt pins (INT1 and INT2). > > At the moment, the driver uses only the first one, which is fine for > > most situations. However, some boards might only have INT2 connected > > for some reason. > > > > Add the necessary bits and configuration to set up INT2. Then try > > to detect this situation at least for device tree setups by checking > > if the first interrupt (the one picked by the I2C/SPI core) is actually > > named "INT2" using the interrupt-names property. > > > > of_irq_get_byname() returns either 0 or some error code in case > > the driver probed without device tree, so in all other cases we fall > > back to configuring INT1 as before. > > > > Signed-off-by: Stephan Gerhold > > > #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. -- With Best Regards, Andy Shevchenko