Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3197550pxv; Mon, 12 Jul 2021 11:37:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7XgosoxGwyVy+2qAnONJtVkt9Z7HxMZUmhlGk5K3pOFamt/sUlRCI8WWlXkeOq7+cWaAx X-Received: by 2002:a17:906:1997:: with SMTP id g23mr511017ejd.304.1626115055757; Mon, 12 Jul 2021 11:37:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626115055; cv=none; d=google.com; s=arc-20160816; b=IILpcIjjCZvj0qyDzDXd3W8JGrvdteikQWUZ3lGjf5dNuEcu/mK6Mv1rO9fXokyMcD SM6IlvVxJmuEG+u65F1ZvMi6xw0vzdki+S2kQoANdvCOOrFwlSBGCq4aDg64M+BC8rBy E5Ie1GCut/IO26Qn8oqPYVDXaAhRwPsW2HctdMfY1J7rX07vUzhSdiN4y634a8wR7uzm xR7snXpNLvx4YVjDE1/NflAHznu4r1JdWPsN/lj/EMjRGRLD8lzVu0+OfKTMf1tIyoET HbZ+mF/9V+aji6lSUOGz5eIbIE+VU43TFuHXJfadEEGRCnRGP+mddJ/AlFw7wjau6GfA 6A/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=FDJgwFGUTs388Xq7i/ky43uQMk6k8nPP0UaxhPLef/s=; b=j2ScV06pGHEqH65IJHnc8hrGZ7Kdj+WoU6E5DNs/Myzm7GDlSG0R4x8kDv2mk0j1+G Jth2CpRTVLZP4bczMfOAGagTK0w8LzdbI7E1kRztJsn5fo1PCtBmN4qJAMb17Dr1rzCF z1xcELcbYUw5BUBKqN9+rAXEzrVv2trrWKHEn6zRr1ex3/J610eK6MFSJG7T+6+aIqvo d4f6ybyCtXZCNxoAu+1wTqiBNgvtEH0/8MxkZAfTLYe4pCzuVOBPsCB6Ms1p65sMBfwI wV5o4aqROlBDFdHCCZXxi/UKmmwRoRUeNKQswI0RISTxijrk6c4IrFMfhAeijfmfLppB InUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z2si17649783edb.563.2021.07.12.11.37.10; Mon, 12 Jul 2021 11:37:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235550AbhGLSi6 (ORCPT + 99 others); Mon, 12 Jul 2021 14:38:58 -0400 Received: from mga05.intel.com ([192.55.52.43]:65212 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230181AbhGLSi5 (ORCPT ); Mon, 12 Jul 2021 14:38:57 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10043"; a="295681284" X-IronPort-AV: E=Sophos;i="5.84,234,1620716400"; d="scan'208";a="295681284" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2021 11:36:07 -0700 X-IronPort-AV: E=Sophos;i="5.84,234,1620716400"; d="scan'208";a="459281025" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2021 11:36:05 -0700 Received: from andy by smile with local (Exim 4.94.2) (envelope-from ) id 1m30md-00CKKX-E9; Mon, 12 Jul 2021 21:35:59 +0300 Date: Mon, 12 Jul 2021 21:35:59 +0300 From: Andy Shevchenko To: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Linux ACPI , LKML , "Krogerus, Heikki" Subject: Re: [PATCH v1 4/6] ACPI: glue: Eliminate acpi_platform_notify() Message-ID: References: <2780027.e9J7NaK4W3@kreacher> <8790139.CDJkKcVGEf@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8790139.CDJkKcVGEf@kreacher> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 12, 2021 at 07:25:55PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Get rid of acpi_platform_notify() which is redundant and > make device_platform_notify() in the driver core call > acpi_device_notify() and acpi_device_notify_remove() directly. > + if (action == KOBJ_ADD) > + acpi_device_notify(dev); > + else if (action == KOBJ_REMOVE) > + acpi_device_notify_remove(dev); In most of the cases we are using switch-case approach with KOBJ_ADD/KOBJ_REMOVE. Would it make sense to keep that pattern? -- With Best Regards, Andy Shevchenko