Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp22123889rwd; Fri, 30 Jun 2023 04:19:23 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5K1iYMln49htGaPxfCvLZpE0HZ+hJ/KRA8HtCRNSMPZo0AvLt2vKizn+HzU1At2sluY25q X-Received: by 2002:a9d:741a:0:b0:6b5:ed7a:1769 with SMTP id n26-20020a9d741a000000b006b5ed7a1769mr2612234otk.16.1688123963684; Fri, 30 Jun 2023 04:19:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688123963; cv=none; d=google.com; s=arc-20160816; b=kfXAbmm4TO9bFLqzUkir1hMI2cC2UxG9X2kxUcxNE5ehZYsTfqHaKOXUMTjoaz2JK0 lJukFl36YhyrRbNe69iMum5JD0bzIpbbDfo9WXGN3zqgn/ZKmLZCEJ+96I5/wBalxQaU AxeGshFh+ZDavlWlLaxUHCTD98fgSmkOYdQzRigoNFk0NyT/HILuh/g+a4EAmfsozCbW dJ32p7ZAjEhVE97XHHEt4KbL6tB3AFJgGINiqGyV/ddB5D0ybbCiFBpLFqMQZdfCwKuV z6myNRLvElU0looF2Ah18JqbYvSXujnxiZUELKfk2yl7hYfhYLgQSqfxErz5tyWDuvtR neoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=+wtchpps+t+A4zKdgRpE1CneAlUVbo4EmnCzFalRat0=; fh=IH5VwK8py+zARKb2mEzZVRjL3isAd365Hq1/XMOa0Oo=; b=CS0MCA471U+AmBK66IkTKQuVLIYSY3vmLP9RPG+e6OH6MERh5n96U8+4BM5sUNV00e Z2U3Uuq1aUzqd03vswtsBXZMtZzJfAIck6YEFwZI7y3VdAflPaj9o03Mn84QNTwhweuW jlSodqf/D1PsX2kGXRlgeGWu+HIF6dBq4KIMnl8duRjtPOG9u29qexB4H6ByaZEcG30f vnjZn6+e38Qfr6b6SQSMQPcoQV5vvDfaPhMHnrhKET3r1KVeXanjEb/XT48wFoYJ7CU+ s7fSqWHBHF1bVwjw2QumZBFsTWj7j2bmv3div8k7l/C9ybmUkcwEHZ4A/NXH/gE5edSD N/Gg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s11-20020a63dc0b000000b005573a9229f0si12999461pgg.841.2023.06.30.04.19.11; Fri, 30 Jun 2023 04:19:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232650AbjF3LCg convert rfc822-to-8bit (ORCPT + 99 others); Fri, 30 Jun 2023 07:02:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232583AbjF3LBx (ORCPT ); Fri, 30 Jun 2023 07:01:53 -0400 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB8D43ABC; Fri, 30 Jun 2023 04:01:17 -0700 (PDT) Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-98dfd15aae1so49306766b.0; Fri, 30 Jun 2023 04:01:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688122859; x=1690714859; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SwNNfkXcsdEjK6snSksErOen+E6g37LU4cCW5pLNENE=; b=FV4YJjZdwOvpL9UrFa6pX9agAOWeBW6KqTDT/5XSVwPnJAOI09HqvShBXcZA03yi3t JPXt8+TjUGYYFHWB0nAYml/GWViUTvYUTIkj7N4Zvcdbsla7pKYJo2Qp/qL59m4H0eT9 D1vju1lvarH5ss8TKWSuk+6OcZ7//HG/8agrNZwMQVflGeEOZgZNzghOvLAhSWJjqhfo Ah0wHLhdNUsxmRH38NTveE3WXI1W8cobHVEF/bCBXq1FpAcxNNaoCTA4pNbQmBNskhvM gYTFLOMAblJF8nZDetZJzFvDGbREqRUbQOpkRbspOUprdU+qPlg3u36BqiQOR7hrxXuj OFrw== X-Gm-Message-State: ABy/qLYgLf5p/9HCB13iUZCbM3c4kmlLV1xXWkXtMgx/TtwtvO2FwQWt u1eofipkj+xG3XQbk1Hgd2JaDapuCVTep4e4mCE= X-Received: by 2002:a17:906:594b:b0:987:f332:5329 with SMTP id g11-20020a170906594b00b00987f3325329mr1488661ejr.1.1688122859289; Fri, 30 Jun 2023 04:00:59 -0700 (PDT) MIME-Version: 1.0 References: <20230616165034.3630141-1-michal.wilczynski@intel.com> <20230616165034.3630141-10-michal.wilczynski@intel.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Fri, 30 Jun 2023 13:00:48 +0200 Message-ID: Subject: Re: [PATCH v5 09/10] acpi/nfit: Move handler installing logic to driver To: "Wilczynski, Michal" Cc: "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, dan.j.williams@intel.com, vishal.l.verma@intel.com, lenb@kernel.org, dave.jiang@intel.com, ira.weiny@intel.com, rui.zhang@intel.com, linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev, "Rafael J . Wysocki" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 30, 2023 at 11:55 AM Wilczynski, Michal wrote: > > > > On 6/29/2023 6:18 PM, Rafael J. Wysocki wrote: > > On Fri, Jun 16, 2023 at 6:51 PM Michal Wilczynski > > wrote: > >> Currently logic for installing notifications from ACPI devices is > >> implemented using notify callback in struct acpi_driver. Preparations > >> are being made to replace acpi_driver with more generic struct > >> platform_driver, which doesn't contain notify callback. Furthermore > >> as of now handlers are being called indirectly through > >> acpi_notify_device(), which decreases performance. > >> > >> Call acpi_dev_install_notify_handler() at the end of .add() callback. > >> Call acpi_dev_remove_notify_handler() at the beginning of .remove() > >> callback. Change arguments passed to the notify function to match with > >> what's required by acpi_install_notify_handler(). Remove .notify > >> callback initialization in acpi_driver. > >> > >> Suggested-by: Rafael J. Wysocki > >> Signed-off-by: Michal Wilczynski > >> --- > >> drivers/acpi/nfit/core.c | 24 ++++++++++++++++++------ > >> 1 file changed, 18 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c > >> index 95930e9d776c..a281bdfee8a0 100644 > >> --- a/drivers/acpi/nfit/core.c > >> +++ b/drivers/acpi/nfit/core.c > >> @@ -3312,11 +3312,13 @@ void acpi_nfit_shutdown(void *data) > >> } > >> EXPORT_SYMBOL_GPL(acpi_nfit_shutdown); > >> > >> -static void acpi_nfit_notify(struct acpi_device *adev, u32 event) > >> +static void acpi_nfit_notify(acpi_handle handle, u32 event, void *data) > >> { > >> - device_lock(&adev->dev); > >> - __acpi_nfit_notify(&adev->dev, adev->handle, event); > >> - device_unlock(&adev->dev); > > It's totally not necessary to rename the ACPI device variable here. > > > > Just add > > > > struct acpi_device *adev = data; > > > > to this function. > > Sure, is adev a preferred name for acpi_device ? In new code, it is. In the existing code, it depends. If you do a one-line change, it is better to retain the original naming (for the sake of clarity of the change itself). If you rearrange it completely, you may as well change the names while at it. And there is a spectrum in between. > I've seen a mix of different naming > in drivers, some use device, adev, acpi_dev and so on. I suppose it's not a big deal, but > it would be good to know. Personally, I prefer adev, but this isn't a very strong preference. Using "device" as a name of a struct acpi_device object (or a pointer to one of these for that matter) is slightly misleading IMV, because those things represent AML entities rather than actual hardware.