Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752449AbdFLJ3g (ORCPT ); Mon, 12 Jun 2017 05:29:36 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:35882 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751955AbdFLJ3d (ORCPT ); Mon, 12 Jun 2017 05:29:33 -0400 MIME-Version: 1.0 In-Reply-To: <6F87890CF0F5204F892DEA1EF0D77A59725BF45D@FMSMSX114.amr.corp.intel.com> References: <1496750118-5570-1-git-send-email-rajmohan.mani@intel.com> <1496750118-5570-3-git-send-email-rajmohan.mani@intel.com> <6F87890CF0F5204F892DEA1EF0D77A59725BF110@FMSMSX114.amr.corp.intel.com> <20170611113007.GV1019@valkosipuli.retiisi.org.uk> <20170611165028.GA12407@valkosipuli.retiisi.org.uk> <6F87890CF0F5204F892DEA1EF0D77A59725BF45D@FMSMSX114.amr.corp.intel.com> From: Andy Shevchenko Date: Mon, 12 Jun 2017 12:29:32 +0300 Message-ID: Subject: Re: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs To: "Mani, Rajmohan" Cc: Sakari Ailus , "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Lee Jones , Linus Walleij , Alexandre Courbot , "Rafael J. Wysocki" , Len Brown 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: 1325 Lines: 34 On Mon, Jun 12, 2017 at 12:17 PM, Mani, Rajmohan wrote: >> Subject: Re: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs >> On Sun, Jun 11, 2017 at 7:50 PM, Sakari Ailus wrote: >> > On Sun, Jun 11, 2017 at 04:40:16PM +0300, Andy Shevchenko wrote: >> >> On Sun, Jun 11, 2017 at 2:30 PM, Sakari Ailus wrote: >> >> > Again, I'm not really worried about this driver, but the ACPI >> >> > tables. How does the difference show there? >> >> >> >> Same way. You will have common numbering over the chip [0, 9]. It >> >> will be just an abstraction inside the driver. >> > Sounds fine to me, taken that this does not add complications to ACPI >> > tables. >> >> They just need to share the same ACPI_HANDLE (it might require to do this in >> generic way in gpiolib) and have a continuous numbering (easy to achieve with >> carefully chosen bases). > Few clarifications... > > Are you implying new kernel changes are needed in gpiolib to accommodate 2 GPIO chips? Might be needed. It should be investigated first. In any case it would be somelike oneliner. > Does it need changes in platform firmware or is it expected to work just with the gpiolib changes that you described above? No firmware changes are implied. -- With Best Regards, Andy Shevchenko