From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH v5] gpio: Add driver for ACPI INT0002 Virtual GPIO device Date: Thu, 1 Jun 2017 17:29:30 +0200 Message-ID: References: <20170524104216.23643-1-hdegoede@redhat.com> <9fae1e2f-9d5b-2ba8-3bf5-4e1516e06332@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <9fae1e2f-9d5b-2ba8-3bf5-4e1516e06332@redhat.com> Sender: linux-acpi-owner@vger.kernel.org To: Hans de Goede Cc: "Rafael J . Wysocki" , Alexandre Courbot , ACPI Devel Maling List , Andy Shevchenko , "linux-gpio@vger.kernel.org" , joeyli , Takashi Iwai List-Id: linux-gpio@vger.kernel.org On Thu, Jun 1, 2017 at 5:20 PM, Hans de Goede wrote: >> So again, the reason this - which is not a GPIO controller at all - >> should anyways >> be in drivers/gpio/ is that some firmware person think it's convenien > >> Shouldn't this rather be in drivers/platform/x86? > > > That is where it started, I'm fine with putting it back there. > >> You can still use the gpio driver abstraction. > > Ack, if you're ok with using the gpio driver abstraction while > putting the driver in drivers/platform/x86 that might be the > best way to deal with this. OK let's proceed like that. I guess I could be hopeless and require that it reimplement the ACPI parser and whatnot just because it's not GPIO but code duplication is a greater evil and thus modelling this as a "GPIO" is the lesser evil, so I just have to accept it as such. Yours, Linus Walleij