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 2AA7BC6FA82 for ; Tue, 13 Sep 2022 18:40:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232371AbiIMSkD (ORCPT ); Tue, 13 Sep 2022 14:40:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230108AbiIMSj2 (ORCPT ); Tue, 13 Sep 2022 14:39:28 -0400 Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0298B70E6E for ; Tue, 13 Sep 2022 11:08:09 -0700 (PDT) Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-1278624b7c4so34368835fac.5 for ; Tue, 13 Sep 2022 11:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=LjK0fulvlnuvLTjKk4E4pqpGI0zifUwgFi6JRD+xi1s=; b=ag1hME6oKmg5TCKzS6jNswj3qklmDcrZ04qFJO5dWFAsGn8l1Y3qTSwXq5Yx1fucPz nmcQ+3uJi9tLtO49mzhRIZAaW0+dYV7eqq1Oo5mErNTYHZaabH+fYqoR2Wl14BsDyCqC 4u7U7rT4w5MarvgyEO9u6vhS7AeusigkSSNTc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=LjK0fulvlnuvLTjKk4E4pqpGI0zifUwgFi6JRD+xi1s=; b=1V+NewQ3XN9fC5GULuKt5nQMh1kVCR4vyDFP8sbtXz8lbseZCIITaJsWxc0kFXj3/p jrN8a3p8iwFOPNgPTlzUTQbqnBD2WpUj3yA8RqLu4odcUrKXYFLHeeJilQAYB3VpEQhW qNRPPw0iGZy1NnnbIoSXIP+mslVe1dA4Z8g8a8CDU7hp9UXDlcXimC711pTJdhAoImcv 43RPI44tJ80v8EpbIEZwCefjEmEWh3YgOaKmI4bFH+jQDPkY9Eqyiaa1n/t+ZqATEMC3 FsH92wm5tpPVmlAZq9xYVmKgp/jADtq92BtEbkFyT+feYO1VrmQFW0dtcoQYf/6o+Pt5 msQw== X-Gm-Message-State: ACgBeo0DyG+PPEVwgZ1fzLNNYuHVgYpEVmQIV+Y7KUja7q1moZ9At3gp VE/usXXRzh5QhSMtQd14HJpJt4dkOkKJqA== X-Google-Smtp-Source: AA6agR5F2C1GjlZf2nlqFyjtRHCO7ptGcnN4Qx/yrv4hP/20udB7L02xfafAxD98m9iTr5WlMQfSZw== X-Received: by 2002:a05:6870:178b:b0:12b:c621:b7a9 with SMTP id r11-20020a056870178b00b0012bc621b7a9mr303754oae.41.1663092488336; Tue, 13 Sep 2022 11:08:08 -0700 (PDT) Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com. [209.85.160.52]) by smtp.gmail.com with ESMTPSA id s10-20020acadb0a000000b0034d14c6ce3dsm5463659oig.16.2022.09.13.11.08.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Sep 2022 11:08:05 -0700 (PDT) Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-1225219ee46so34360240fac.2 for ; Tue, 13 Sep 2022 11:08:04 -0700 (PDT) X-Received: by 2002:a05:6871:808:b0:127:69af:9adf with SMTP id q8-20020a056871080800b0012769af9adfmr322361oap.120.1663092484148; Tue, 13 Sep 2022 11:08:04 -0700 (PDT) MIME-Version: 1.0 References: <20220912221317.2775651-1-rrangel@chromium.org> <20220912160931.v2.7.I8af4282adc72eb9f247adcd03676a43893a020a6@changeid> In-Reply-To: From: Raul Rangel Date: Tue, 13 Sep 2022 12:07:53 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 07/13] i2c: acpi: Use ACPI wake capability bit to set wake_irq To: Andy Shevchenko Cc: Linux ACPI , linux-input , "jingle.wu" , "Limonciello, Mario" , Tim Van Patten , Linus Walleij , Hans de Goede , "Rafael J. Wysocki" , Mika Westerberg , Wolfram Sang , "open list:I2C SUBSYSTEM HOST DRIVERS" , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org On Tue, Sep 13, 2022 at 11:26 AM Andy Shevchenko wrote: > > On Mon, Sep 12, 2022 at 04:13:11PM -0600, Raul E Rangel wrote: > > Device tree already has a mechanism to pass the wake_irq. It does this > > by looking for the wakeup-source property and setting the > > I2C_CLIENT_WAKE flag. This CL adds the ACPI equivalent. It uses the > > ACPI interrupt wake flag to determine if the interrupt can be used to > > wake the system. Previously the i2c drivers had to make assumptions and > > blindly enable the wake IRQ. This can cause spurious wake events. e.g., > > If there is a device with an Active Low interrupt and the device gets > > powered off while suspending, the interrupt line will go low since it's > > no longer powered and wakes the system. For this reason we should > > respect the board designers wishes and honor the wake bit defined on the > > interrupt. > > > + if (irq > 0 && acpi_wake_capable) > > + client->flags |= I2C_CLIENT_WAKE; > > Why do we need a parameter and can't simply set this flag inside the callee? Are you suggesting `i2c_acpi_get_irq` modify the `client->flags`? IMO that's a little surprising since the I wouldn't expect a `get` function to modify it's parameters. I'm fine implementing it if others agree though.