Message ID | 20221108142226.63161-4-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2740961wru; Tue, 8 Nov 2022 06:28:20 -0800 (PST) X-Google-Smtp-Source: AA0mqf5lmvJRHJlV6i92q8Fl0k1ZaWzsTSF1viDIvGOCy1rJk/AfNWefheY6Jp+62hf0y0Tcu1Ue X-Received: by 2002:a17:902:a401:b0:188:79ba:d542 with SMTP id p1-20020a170902a40100b0018879bad542mr15235720plq.126.1667917700269; Tue, 08 Nov 2022 06:28:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667917700; cv=none; d=google.com; s=arc-20160816; b=in493ELJPILO37fmzqarDpBq/BI5sAp4A/n1eAQeIsae0areCK5XSZ2uh53BmuIfNk hRSUeFNal+wCSvQdAeM61p2EIQydJEGxiuy2KEMIwVCSu0KSv+YXIbyoH8S41rKxN0VW yourRZnSexyF6clL3O4kgxwkHQaPfunOmVh/SrNvYOpeSC5S2zznaGfqZPT25O+nsJAV hsEe9Ubo+65zB4LTxtbRubUHxJxrBoBBu7HgQJ4mgST0LKTrO97Qjbax4+B75dbL+EZr /Ckuek7XDnWmZIfeopiSHew/zJ2qT6ICg8cSW5h10TkIg6h3WnntRw9+8tqZdOKsRI7u rlkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Gry1qXs3puA6+vjs1Qo+vfBKKNvG3UM/+7ig2JiH1Pg=; b=oudJvPFwuoxUXoVpfLq9R/42bbMeOnS6zZiMD9eXIGuW/A70gLLaKuL60JYlkjBg/k jkn4hhs0AldfPRNWYuJGSPfLjxD+ohAcNmkgfTdHluKnnSAm/iCRPTHz7eu5zFT0ujA4 9t9BZaTizI2pDVZbo61dr6Zpto6IbQ/VBQMa7FQyXHgjQzIjWADGpz7VHwdi2VVh/YZa kNxG/r3ZcL/Bz9qpCBq3Dq2huI21edZhdoENUAnTqw4hPiSpFJcZqVtutUFiG3/Xz2Eb RZFHbueJrj/P/7D8PR0fyeMf/WQoTMyLFX39WW91U3nWF1XMyMUxlE/fhlUpKYPQ1tca vhQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZN261CEa; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ik9-20020a170902ab0900b00176a8746df6si12902113plb.433.2022.11.08.06.28.06; Tue, 08 Nov 2022 06:28:20 -0800 (PST) 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; dkim=pass header.i=@intel.com header.s=Intel header.b=ZN261CEa; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234181AbiKHOWg (ORCPT <rfc822;tony84727@gmail.com> + 99 others); Tue, 8 Nov 2022 09:22:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234583AbiKHOWI (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 8 Nov 2022 09:22:08 -0500 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 374E854B0D; Tue, 8 Nov 2022 06:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667917327; x=1699453327; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=3WwHPrGYys4CM9wArmF05npxQAsVuUHXIQrsJgDTthA=; b=ZN261CEaHOZHPI3HLUxY/UrppgnZgBuZlNn6VI7quBnUwrN+lgWzoSpV BeD07CBevYXyfrgUE7VivGWGNRJLLlZ/v5wCpU5Hs6lL8WaIvG4JYgqTo XQdd6VhQnJxjLgQv1pxZ08nM+l6aknOuwLSFmRwB5A8u5aejyA2aIr5AS qbbPGgsbBKb+Xbk2JHquK5RkHr5La0WZ/CjBSmd9gJaOJSrem6mBoOlhK Je0++cTO4vurwqRM/5P12zDOvgCrSt9MBrjffd7lnGpILcHYrW3u+87A5 cAoydPJl9VgeiAIoHmhrrTPlYSDAHKf/oSON+xzOm9rKTOyeHgbC1xYPM A==; X-IronPort-AV: E=McAfee;i="6500,9779,10524"; a="298219278" X-IronPort-AV: E=Sophos;i="5.96,148,1665471600"; d="scan'208";a="298219278" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2022 06:22:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10524"; a="699938289" X-IronPort-AV: E=Sophos;i="5.96,148,1665471600"; d="scan'208";a="699938289" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga008.fm.intel.com with ESMTP; 08 Nov 2022 06:22:03 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id 7D7B92B7; Tue, 8 Nov 2022 16:22:27 +0200 (EET) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Mika Westerberg <mika.westerberg@linux.intel.com>, Hans de Goede <hdegoede@redhat.com>, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>, Thierry Reding <thierry.reding@gmail.com>, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, linux-pwm@vger.kernel.org Cc: Andy Shevchenko <andy@kernel.org>, Linus Walleij <linus.walleij@linaro.org> Subject: [PATCH v2 3/6] pwm: lpss: Include headers we are direct user of Date: Tue, 8 Nov 2022 16:22:23 +0200 Message-Id: <20221108142226.63161-4-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20221108142226.63161-1-andriy.shevchenko@linux.intel.com> References: <20221108142226.63161-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748938470715331867?= X-GMAIL-MSGID: =?utf-8?q?1748938470715331867?= |
Series |
pinctrl: intel: Enable PWM optional feature
|
|
Commit Message
Andy Shevchenko
Nov. 8, 2022, 2:22 p.m. UTC
For the sake of integrity, include headers we are direct user of. While at it, move the struct pwm_lpss_chip to be after the struct pwm_lpss_boardinfo as the former uses pointer to the latter. Replace device.h with a forward declaration in order to improve the compilation time due to reducing overhead of device.h parsing with entire train of dependencies. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> --- drivers/pwm/pwm-lpss.h | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
Comments
Hello, On Tue, Nov 08, 2022 at 04:22:23PM +0200, Andy Shevchenko wrote: > For the sake of integrity, include headers we are direct user of. > > While at it, move the struct pwm_lpss_chip to be after > the struct pwm_lpss_boardinfo as the former uses pointer > to the latter. That part is fine. > Replace device.h with a forward declaration in order to improve > the compilation time due to reducing overhead of device.h parsing > with entire train of dependencies. Together with "For the sake of integrity, include headers we are direct user of." this makes an a bit schizophrenic impression on me. You add <linux/types.h> because the file is a direct user of it, but you drop <linux/device.h> despite being a direct user. If you adapt the reasoning to something like: Replace the inclusion of <linux/device.h> by a forward declaration of struct device plus a (cheaper) #include of <linux/types.h> as <linux/device.h> is an expensive include (measured in compiler effort). I could better live with it. I would even split this into two patches then. (i.e. move struct pwm_lpss_chip vs the include and forward change) Best regards Uwe
On Thu, Nov 10, 2022 at 9:22 AM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > On Tue, Nov 08, 2022 at 04:22:23PM +0200, Andy Shevchenko wrote: > > For the sake of integrity, include headers we are direct user of. > > > > While at it, move the struct pwm_lpss_chip to be after > > the struct pwm_lpss_boardinfo as the former uses pointer > > to the latter. > > That part is fine. > > > Replace device.h with a forward declaration in order to improve > > the compilation time due to reducing overhead of device.h parsing > > with entire train of dependencies. > > Together with "For the sake of integrity, include headers we are direct > user of." this makes an a bit schizophrenic impression on me. You add > <linux/types.h> because the file is a direct user of it, but you drop > <linux/device.h> despite being a direct user. But we don't use device.h. > If you adapt the reasoning to something like: > > Replace the inclusion of <linux/device.h> by a forward declaration of > struct device plus a (cheaper) #include of <linux/types.h> as > <linux/device.h> is an expensive include (measured in compiler effort). Fine with me, thanks for the draft. > I could better live with it. I would even split this into two patches > then. (i.e. move struct pwm_lpss_chip vs the include and forward change) I think for this small change for a driver that hasn't been modified often it's fine to have them in one. But tell me if you are insisting on a split, I can do that.
On Thu, Nov 10, 2022 at 11:53:59AM +0200, Andy Shevchenko wrote: > On Thu, Nov 10, 2022 at 9:22 AM Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > On Tue, Nov 08, 2022 at 04:22:23PM +0200, Andy Shevchenko wrote: > > > For the sake of integrity, include headers we are direct user of. > > > > > > While at it, move the struct pwm_lpss_chip to be after > > > the struct pwm_lpss_boardinfo as the former uses pointer > > > to the latter. > > > > That part is fine. > > > > > Replace device.h with a forward declaration in order to improve > > > the compilation time due to reducing overhead of device.h parsing > > > with entire train of dependencies. > > > > Together with "For the sake of integrity, include headers we are direct > > user of." this makes an a bit schizophrenic impression on me. You add > > <linux/types.h> because the file is a direct user of it, but you drop > > <linux/device.h> despite being a direct user. > > But we don't use device.h. What is the canonical header to provide struct device? > > If you adapt the reasoning to something like: > > > > Replace the inclusion of <linux/device.h> by a forward declaration of > > struct device plus a (cheaper) #include of <linux/types.h> as > > <linux/device.h> is an expensive include (measured in compiler effort). > > Fine with me, thanks for the draft. > > > I could better live with it. I would even split this into two patches > > then. (i.e. move struct pwm_lpss_chip vs the include and forward change) > > I think for this small change for a driver that hasn't been modified > often it's fine to have them in one. But tell me if you are insisting > on a split, I can do that. I don't insist. Best regards Uwe
On Thu, Nov 10, 2022 at 12:20 PM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > On Thu, Nov 10, 2022 at 11:53:59AM +0200, Andy Shevchenko wrote: > > On Thu, Nov 10, 2022 at 9:22 AM Uwe Kleine-König > > <u.kleine-koenig@pengutronix.de> wrote: > > > On Tue, Nov 08, 2022 at 04:22:23PM +0200, Andy Shevchenko wrote: ... > > > > Replace device.h with a forward declaration in order to improve > > > > the compilation time due to reducing overhead of device.h parsing > > > > with entire train of dependencies. > > > > > > Together with "For the sake of integrity, include headers we are direct > > > user of." this makes an a bit schizophrenic impression on me. You add > > > <linux/types.h> because the file is a direct user of it, but you drop > > > <linux/device.h> despite being a direct user. > > > > But we don't use device.h. > > What is the canonical header to provide struct device? But we don't use the struct device here. We use _pointer_ to a struct device.
diff --git a/drivers/pwm/pwm-lpss.h b/drivers/pwm/pwm-lpss.h index 2c746c51b883..4561d229b27d 100644 --- a/drivers/pwm/pwm-lpss.h +++ b/drivers/pwm/pwm-lpss.h @@ -10,16 +10,12 @@ #ifndef __PWM_LPSS_H #define __PWM_LPSS_H -#include <linux/device.h> #include <linux/pwm.h> +#include <linux/types.h> -#define LPSS_MAX_PWMS 4 +struct device; -struct pwm_lpss_chip { - struct pwm_chip chip; - void __iomem *regs; - const struct pwm_lpss_boardinfo *info; -}; +#define LPSS_MAX_PWMS 4 struct pwm_lpss_boardinfo { unsigned long clk_rate; @@ -43,6 +39,12 @@ extern const struct pwm_lpss_boardinfo pwm_lpss_bsw_info; extern const struct pwm_lpss_boardinfo pwm_lpss_bxt_info; extern const struct pwm_lpss_boardinfo pwm_lpss_tng_info; +struct pwm_lpss_chip { + struct pwm_chip chip; + void __iomem *regs; + const struct pwm_lpss_boardinfo *info; +}; + struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, void __iomem *base, const struct pwm_lpss_boardinfo *info);