Message ID | 20221010201453.77401-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
---|---|
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1ohzB8-004sT7-CA; Mon, 10 Oct 2022 20:15:13 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229630AbiJJUPF (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Mon, 10 Oct 2022 16:15:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229502AbiJJUPB (ORCPT <rfc822;linux-media@vger.kernel.org>); Mon, 10 Oct 2022 16:15:01 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AE9330F76; Mon, 10 Oct 2022 13:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665432899; x=1696968899; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=hoHtp7ua/tOZfAXpLOK1gBSb/sEyQkWFQ6Xh4kF5nfY=; b=HubOx1wdiYmCEBX6FHOglY66/019WVdLKdldl1tmK89hflxiia2wDcwC YFSxDYvlzHjqcHty7/l4oLWatyOdIwzfzalp4tD5YDDOSiSIBzQfR1vo5 kgBHAvWO+IWbXTpQAqjP28BiO4A0dxflwDUJ4Ffs5gpXjBG6FsQHcCdm2 gyCH+p3hKUiA5LG1qKn8dA8xlZExfbDjLU21MnMstn/DFZQz8QIIb95gh jN8vNEaCyCU0jwOyKYULlrh66HJCVNaIkXWL3AiDeeu94GdJ1Hk4XZBur 8k64Q6RiU+2kjKsnl8trzwMbxHvp7xaFlkUocScYOy0fdkTC4+TfI4sNO A==; X-IronPort-AV: E=McAfee;i="6500,9779,10496"; a="303065999" X-IronPort-AV: E=Sophos;i="5.95,173,1661842800"; d="scan'208";a="303065999" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2022 13:14:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10496"; a="603862730" X-IronPort-AV: E=Sophos;i="5.95,173,1661842800"; d="scan'208";a="603862730" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga006.jf.intel.com with ESMTP; 10 Oct 2022 13:14:48 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 8E95D1C8; Mon, 10 Oct 2022 23:15:08 +0300 (EEST) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Marc Zyngier <maz@kernel.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Bartosz Golaszewski <brgl@bgdev.pl>, Kent Gibson <warthog618@gmail.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Billy Tsai <billy_tsai@aspeedtech.com>, Thomas Gleixner <tglx@linutronix.de>, Linus Walleij <linus.walleij@linaro.org>, Mika Westerberg <mika.westerberg@linux.intel.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Chen-Yu Tsai <wenst@chromium.org>, Claudiu Beznea <claudiu.beznea@microchip.com>, Samuel Holland <samuel@sholland.org>, Horatiu Vultur <horatiu.vultur@microchip.com>, =?utf-8?b?UmFmYcWCIE1pxYJl?= =?utf-8?b?Y2tp?= <rafal@milecki.pl>, Bjorn Andersson <bjorn.andersson@linaro.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Geert Uytterhoeven <geert+renesas@glider.be>, Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>, Phil Edworthy <phil.edworthy@renesas.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Fabien Dessenne <fabien.dessenne@foss.st.com>, Prathamesh Shete <pshete@nvidia.com>, Basavaraj Natikar <Basavaraj.Natikar@amd.com>, linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, linux-actions@lists.infradead.org, linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org, linux-rpi-kernel@lists.infradead.org, alsa-devel@alsa-project.org, patches@opensource.cirrus.com, linux-mediatek@lists.infradead.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, linux-omap@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-msm@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-samsung-soc@vger.kernel.org Cc: Thierry Reding <thierry.reding@gmail.com>, Jonathan Hunter <jonathanh@nvidia.com>, Patrice Chotard <patrice.chotard@foss.st.com>, =?utf-8?q?Andreas_F=C3=A4rbe?= =?utf-8?q?r?= <afaerber@suse.de>, Manivannan Sadhasivam <mani@kernel.org>, Andrew Jeffery <andrew@aj.id.au>, Joel Stanley <joel@jms.id.au>, Florian Fainelli <f.fainelli@gmail.com>, Ray Jui <rjui@broadcom.com>, Scott Branden <sbranden@broadcom.com>, Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, Charles Keepax <ckeepax@opensource.cirrus.com>, Richard Fitzgerald <rf@opensource.cirrus.com>, Dong Aisheng <aisheng.dong@nxp.com>, Fabio Estevam <festevam@gmail.com>, Shawn Guo <shawnguo@kernel.org>, Jacky Bai <ping.bai@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Sascha Hauer <s.hauer@pengutronix.de>, NXP Linux Team <linux-imx@nxp.com>, Andy Shevchenko <andy@kernel.org>, Sean Wang <sean.wang@kernel.org>, Andrew Lunn <andrew@lunn.ch>, Gregory Clement <gregory.clement@bootlin.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>, Avi Fishman <avifishman70@gmail.com>, Tomer Maimon <tmaimon77@gmail.com>, Tali Perry <tali.perry1@gmail.com>, Patrick Venture <venture@google.com>, Nancy Yuen <yuenn@google.com>, Benjamin Fair <benjaminfair@google.com>, Ludovic Desroches <ludovic.desroches@microchip.com>, Nicolas Ferre <nicolas.ferre@microchip.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Chen-Yu Tsai <wens@csie.org>, Paul Cercueil <paul@crapouillou.net>, Damien Le Moal <damien.lemoal@wdc.com>, Tony Lindgren <tony@atomide.com>, Haojian Zhuang <haojian.zhuang@linaro.org>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Michal Simek <michal.simek@xilinx.com>, Andy Gross <agross@kernel.org>, Konrad Dybcio <konrad.dybcio@somainline.org>, Tomasz Figa <tomasz.figa@gmail.com>, Sylwester Nawrocki <s.nawrocki@samsung.com>, Alim Akhtar <alim.akhtar@samsung.com>, Viresh Kumar <vireshk@kernel.org>, Shiraz Hashim <shiraz.linux.kernel@gmail.com>, soc@kernel.org, Orson Zhai <orsonzhai@gmail.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, Chunyan Zhang <zhang.lyra@gmail.com>, Emil Renner Berthing <kernel@esmil.dk>, Kunihiko Hayashi <hayashi.kunihiko@socionext.com>, Masami Hiramatsu <mhiramat@kernel.org> Subject: [rft, PATCH v2 00/36] pinctrl: Clean up and add missed headers Date: Mon, 10 Oct 2022 23:14:16 +0300 Message-Id: <20221010201453.77401-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.35.1 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,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-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -2.4 (--) X-LSpam-Report: No, score=-2.4 required=5.0 tests=BAYES_00=-1.9,DKIMWL_WL_HIGH=0.001,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1 autolearn=ham autolearn_force=no |
Series |
pinctrl: Clean up and add missed headers
|
|
Message
Andy Shevchenko
Oct. 10, 2022, 8:14 p.m. UTC
Currently the header inclusion inside the pinctrl headers seems more arbitrary than logical. This series is basically out of two parts: - add missed headers to the pin control drivers / users - clean up the headers of pin control subsystem The idea is to have this series to be pulled after -rc1 by the GPIO and pin control subsystems, so all new drivers will utilize cleaned up headers of the pin control. Please, review and comment. Changelog v2: - added preparatory patches: all, but last (LKP) - added missed forward declaration to the last patch (LKP) Andy Shevchenko (36): gpiolib: tegra186: Add missed header(s) gpiolib: cdev: Add missed header(s) media: c8sectpfe: Add missed header(s) pinctrl: actions: Add missed header(s) pinctrl: aspeed: Add missed header(s) pinctrl: at91: Add missed header(s) pinctrl: axp209: Add missed header(s) pinctrl: bcm: Add missed header(s) pinctrl: cygnus-mux: Add missed header(s) pinctrl: imx: Add missed header(s) pinctrl: ingenic: Add missed header(s) pinctrl: k210: Add missed header(s) pinctrl: lochnagar: Add missed header(s) pinctrl: mediatek: Add missed header(s) pinctrl: mvebu: Add missed header(s) pinctrl: npcm7xx: Add missed header(s) pinctrl: ocelot: Add missed header(s) pinctrl: qcom: Add missed header(s) pinctrl: renesas: Add missed header(s) pinctrl: samsung: Add missed header(s) pinctrl: single: Add missed header(s) pinctrl: spear: Add missed header(s) pinctrl: sprd: Add missed header(s) pinctrl: st: Add missed header(s) pinctrl: starfive: Add missed header(s) pinctrl: stm32: Add missed header(s) pinctrl: stmfx: Add missed header(s) pinctrl: tegra: Add missed header(s) pinctrl: ti-iodelay: Add missed header(s) pinctrl: uniphier: Add missed header(s) pinctrl: zynqmp: Add missed header(s) pinctrl: cherryview: Add missed header(s) pinctrl: lynxpoint: Add missed header(s) pinctrl: merrifield: Add missed header(s) pinctrl: intel: Add missed header(s) pinctrl: Clean up headers drivers/gpio/gpio-tegra186.c | 3 +- drivers/gpio/gpiolib-cdev.c | 6 ++-- .../st/sti/c8sectpfe/c8sectpfe-core.c | 8 +++-- drivers/pinctrl/actions/pinctrl-owl.c | 10 +++--- drivers/pinctrl/aspeed/pinctrl-aspeed.c | 1 + drivers/pinctrl/bcm/pinctrl-bcm281xx.c | 13 +++++--- drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 9 ++++-- drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 12 ++++--- drivers/pinctrl/bcm/pinctrl-ns2-mux.c | 8 +++-- drivers/pinctrl/bcm/pinctrl-nsp-mux.c | 8 +++-- drivers/pinctrl/cirrus/pinctrl-lochnagar.c | 6 ++-- drivers/pinctrl/core.c | 19 ++++++------ drivers/pinctrl/core.h | 12 ++++++- drivers/pinctrl/devicetree.h | 6 ++++ drivers/pinctrl/freescale/pinctrl-imx.c | 8 +++-- drivers/pinctrl/intel/pinctrl-cherryview.c | 6 ++-- drivers/pinctrl/intel/pinctrl-intel.c | 6 ++-- drivers/pinctrl/intel/pinctrl-lynxpoint.c | 6 ++-- drivers/pinctrl/intel/pinctrl-merrifield.c | 4 ++- drivers/pinctrl/mediatek/pinctrl-moore.c | 3 ++ drivers/pinctrl/mediatek/pinctrl-paris.c | 5 +++ drivers/pinctrl/mvebu/pinctrl-mvebu.c | 14 +++++---- drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 11 ++++--- drivers/pinctrl/pinconf.h | 10 ++++++ drivers/pinctrl/pinctrl-at91-pio4.c | 10 ++++-- drivers/pinctrl/pinctrl-at91.c | 16 +++++----- drivers/pinctrl/pinctrl-axp209.c | 8 +++-- drivers/pinctrl/pinctrl-ingenic.c | 10 +++--- drivers/pinctrl/pinctrl-k210.c | 12 ++++--- drivers/pinctrl/pinctrl-ocelot.c | 10 +++--- drivers/pinctrl/pinctrl-single.c | 5 ++- drivers/pinctrl/pinctrl-st.c | 21 ++++++++----- drivers/pinctrl/pinctrl-stmfx.c | 2 ++ drivers/pinctrl/pinctrl-utils.h | 5 +++ drivers/pinctrl/pinctrl-zynqmp.c | 4 ++- drivers/pinctrl/pinmux.c | 17 +++++----- drivers/pinctrl/pinmux.h | 11 +++++++ drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 8 +++-- drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 8 +++-- drivers/pinctrl/renesas/pinctrl-rzg2l.c | 7 +++-- drivers/pinctrl/renesas/pinctrl-rzv2m.c | 4 ++- drivers/pinctrl/renesas/pinctrl.c | 8 +++-- drivers/pinctrl/samsung/pinctrl-samsung.c | 11 ++++--- drivers/pinctrl/spear/pinctrl-spear.c | 6 ++-- drivers/pinctrl/sprd/pinctrl-sprd.c | 6 ++-- .../starfive/pinctrl-starfive-jh7100.c | 2 ++ drivers/pinctrl/stm32/pinctrl-stm32.c | 16 +++++----- drivers/pinctrl/tegra/pinctrl-tegra.c | 6 ++-- drivers/pinctrl/ti/pinctrl-ti-iodelay.c | 8 +++-- .../pinctrl/uniphier/pinctrl-uniphier-core.c | 8 +++-- include/linux/pinctrl/consumer.h | 31 +++++++++---------- include/linux/pinctrl/devinfo.h | 6 ++-- include/linux/pinctrl/machine.h | 8 +++-- include/linux/pinctrl/pinconf-generic.h | 23 ++++++++------ include/linux/pinctrl/pinctrl.h | 18 +++++------ include/linux/pinctrl/pinmux.h | 5 ++- 56 files changed, 328 insertions(+), 186 deletions(-) base-commit: 9d157c89c5569f0ef560b7a5b2d7bf59ae98499c
Comments
On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > than logical. This series is basically out of two parts: > - add missed headers to the pin control drivers / users > - clean up the headers of pin control subsystem > > The idea is to have this series to be pulled after -rc1 by the GPIO and > pin control subsystems, so all new drivers will utilize cleaned up headers > of the pin control. > > Please, review and comment. > > Changelog v2: > - added preparatory patches: all, but last (LKP) > - added missed forward declaration to the last patch (LKP) > Thanks for doing this. Did you use any kind of automation for detecting for which symbols the headers are missing? Bart
On Tue, Oct 11, 2022 at 09:10:07AM +0200, Bartosz Golaszewski wrote: > On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > than logical. This series is basically out of two parts: > > - add missed headers to the pin control drivers / users > > - clean up the headers of pin control subsystem > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > pin control subsystems, so all new drivers will utilize cleaned up headers > > of the pin control. > > > > Please, review and comment. > > > > Changelog v2: > > - added preparatory patches: all, but last (LKP) > > - added missed forward declaration to the last patch (LKP) > > Thanks for doing this. You're welcome! > Did you use any kind of automation for > detecting for which symbols the headers are missing? No, it's manual + what CI(s) reported back to me, that's why even in this series I have got a few compile breakages. I have very limited compile-testing cycle.
On 10/10/2022 1:14 PM, Andy Shevchenko wrote: > Currently the header inclusion inside the pinctrl headers seems more arbitrary > than logical. This series is basically out of two parts: > - add missed headers to the pin control drivers / users > - clean up the headers of pin control subsystem > > The idea is to have this series to be pulled after -rc1 by the GPIO and > pin control subsystems, so all new drivers will utilize cleaned up headers > of the pin control. > > Please, review and comment. Did you really need to split this on a per-driver basis as opposed to just a treewide drivers/pinctrl, drivers/media and drivers/gpiolib patch set? 36 patches seems needlessly high when 4 patches could have achieve the same outcome.
On Tue, Oct 11, 2022 at 11:56 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > On 10/10/2022 1:14 PM, Andy Shevchenko wrote: > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > than logical. This series is basically out of two parts: > > - add missed headers to the pin control drivers / users > > - clean up the headers of pin control subsystem > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > pin control subsystems, so all new drivers will utilize cleaned up headers > > of the pin control. > > > > Please, review and comment. > > Did you really need to split this on a per-driver basis as opposed to > just a treewide drivers/pinctrl, drivers/media and drivers/gpiolib patch > set? > > 36 patches seems needlessly high when 4 patches could have achieve the > same outcome. I can combine them if maintainers ask for that, nevertheless for Intel pin control and GPIO drivers, which I care more about, I would like to leave as separate changes (easy to see in history what was done).
On Wed, Oct 12, 2022 at 01:04:10PM +0300, Andy Shevchenko wrote: > On Tue, Oct 11, 2022 at 11:56 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > On 10/10/2022 1:14 PM, Andy Shevchenko wrote: > > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > > than logical. This series is basically out of two parts: > > > - add missed headers to the pin control drivers / users > > > - clean up the headers of pin control subsystem > > > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > > pin control subsystems, so all new drivers will utilize cleaned up headers > > > of the pin control. > > > > > > Please, review and comment. > > > > Did you really need to split this on a per-driver basis as opposed to > > just a treewide drivers/pinctrl, drivers/media and drivers/gpiolib patch > > set? > > > > 36 patches seems needlessly high when 4 patches could have achieve the > > same outcome. > > I can combine them if maintainers ask for that, nevertheless for Intel > pin control and GPIO drivers, which I care more about, I would like to > leave as separate changes (easy to see in history what was done). I can now tell why I don't like to combine. While doing a revert (it's not related to GPIO nor to pin control), it appears that I reverted extra bits as merge conflict resolution. This is per se is not an issue, but when I tried to find and reapply that missed piece I can't, because the patch is combined and Git simply ignores to have `git cherry-pick _something in the past_` done. But again, up to maintainers.
On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > Currently the header inclusion inside the pinctrl headers seems more arbitrary > than logical. This series is basically out of two parts: > - add missed headers to the pin control drivers / users > - clean up the headers of pin control subsystem > > The idea is to have this series to be pulled after -rc1 by the GPIO and > pin control subsystems, so all new drivers will utilize cleaned up headers > of the pin control. Aha I see you want to send a pull request so I backed out the applied patches from the series for now. Yours, Linus Walleij
On Mon, Oct 17, 2022 at 11:02:09AM +0200, Linus Walleij wrote: > On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > than logical. This series is basically out of two parts: > > - add missed headers to the pin control drivers / users > > - clean up the headers of pin control subsystem > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > pin control subsystems, so all new drivers will utilize cleaned up headers > > of the pin control. > > Aha I see you want to send a pull request so I backed out the applied patches > from the series for now. Can I consider all that you answered to as Rb tag?
On Mon, Oct 17, 2022 at 11:27 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Mon, Oct 17, 2022 at 11:02:09AM +0200, Linus Walleij wrote: > > On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > > than logical. This series is basically out of two parts: > > > - add missed headers to the pin control drivers / users > > > - clean up the headers of pin control subsystem > > > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > > pin control subsystems, so all new drivers will utilize cleaned up headers > > > of the pin control. > > > > Aha I see you want to send a pull request so I backed out the applied patches > > from the series for now. > > Can I consider all that you answered to as Rb tag? Acked-by: Linus Walleij <linus.walleij@linaro.org> I haven't reviewed in detail but I fully trust you to do the right thing and fix any fallout so will happily pull this. Yours, Linus Walleij
On Mon, Oct 17, 2022 at 11:58:03AM +0200, Linus Walleij wrote: > On Mon, Oct 17, 2022 at 11:27 AM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Oct 17, 2022 at 11:02:09AM +0200, Linus Walleij wrote: > > > On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > > > than logical. This series is basically out of two parts: > > > > - add missed headers to the pin control drivers / users > > > > - clean up the headers of pin control subsystem > > > > > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > > > pin control subsystems, so all new drivers will utilize cleaned up headers > > > > of the pin control. > > > > > > Aha I see you want to send a pull request so I backed out the applied patches > > > from the series for now. > > > > Can I consider all that you answered to as Rb tag? > > Acked-by: Linus Walleij <linus.walleij@linaro.org> Thank you! > I haven't reviewed in detail but I fully trust you to do the right thing > and fix any fallout so will happily pull this. The plan is to push this to Linux Next for a couple of days and then I'll send PR to you and Bart.