Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751901AbdHALF2 (ORCPT ); Tue, 1 Aug 2017 07:05:28 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:35494 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751727AbdHALE2 (ORCPT ); Tue, 1 Aug 2017 07:04:28 -0400 MIME-Version: 1.0 In-Reply-To: References: <1499140415-31677-1-git-send-email-yamada.masahiro@socionext.com> <1499162760.22624.246.camel@linux.intel.com> <1501509867.29303.303.camel@linux.intel.com> From: Andy Shevchenko Date: Tue, 1 Aug 2017 14:04:26 +0300 Message-ID: Subject: Re: [PATCH] gpio: drop unnecessary includes from include/linux/gpio/driver.h To: Linus Walleij Cc: Andy Shevchenko , Masahiro Yamada , "linux-gpio@vger.kernel.org" , Grygorii Strashko , William Breathitt Gray , Ray Jui , =?UTF-8?Q?S=C3=B6ren_Brinkmann?= , David Cohen , Scott Branden , ACPI Devel Maling List , bcm-kernel-feedback-list , Florian Fainelli , Thierry Reding , Jonathan Hunter , Alexander Shiyan , Michal Simek , Kevin Hilman , "linux-tegra@vger.kernel.org" , Joel Stanley , Linux-OMAP , "linux-arm-kernel@lists.infradead.org" , Mika Westerberg , patches@opensource.cirrus.com, Alban Bedel , "linux-kernel@vger.kernel.org" , Santosh Shilimkar , Thor Thayer , Tien Hock Loh Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1347 Lines: 37 On Tue, Aug 1, 2017 at 10:53 AM, Linus Walleij wrote: > On Mon, Jul 31, 2017 at 4:04 PM, Andy Shevchenko > wrote: >> On Mon, 2017-07-31 at 15:48 +0200, Linus Walleij wrote: >>> On Tue, Jul 4, 2017 at 12:06 PM, Andy Shevchenko >>> wrote: >>> > If Linus is okay with the following proposal I would rather go with >>> > it, >>> > i.e. logical split the series to >>> > >>> > 1. Fix IRQ related headers inclusion >>> > 2. Fix pinconf-generic.h inclusion >>> > 3. Fix OF headers inclusion (btw, of_gpio.h is not enough there?) >>> >>> That works fine with me, but also one big patch actually, I do not >>> want to make it too much work to refactor obviously incorrect things. >>> >>> As soon as we have rough consensus on this and the build robot >>> are happy I will apply it to GPIO and also pull it into the pinctrl >>> subsystem. >> >> For me priorities like this: >> 1) it works after the patch being applied (no regressions); >> 2) it makes code cleaner at the end; >> 3) it is presented in logically split parts. >> >> So, as long as 1) and 2) are satisfied I can neglect on 3). > > We are in violent agreement :D What I would like to say is that is up to you after all :-) For me looks better to split. -- With Best Regards, Andy Shevchenko