Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752493AbdFLJOX (ORCPT ); Mon, 12 Jun 2017 05:14:23 -0400 Received: from mga14.intel.com ([192.55.52.115]:52583 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752444AbdFLJOV (ORCPT ); Mon, 12 Jun 2017 05:14:21 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,333,1493708400"; d="scan'208";a="97029105" From: "Mani, Rajmohan" To: Andy Shevchenko CC: "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" Subject: RE: [PATCH v2 2/3] gpio: Add support for TPS68470 GPIOs Thread-Topic: [PATCH v2 2/3] gpio: Add support for TPS68470 GPIOs Thread-Index: AQHS4npdZUk6+PbrsU2O384zfXas5aIgIe2AgADRHWA= Date: Mon, 12 Jun 2017 09:14:16 +0000 Message-ID: <6F87890CF0F5204F892DEA1EF0D77A59725BF44A@FMSMSX114.amr.corp.intel.com> References: <1497161395-36504-1-git-send-email-rajmohan.mani@intel.com> <1497161395-36504-3-git-send-email-rajmohan.mani@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v5C9ERSI029255 Content-Length: 869 Lines: 29 Hi Andy, > Subject: Re: [PATCH v2 2/3] gpio: Add support for TPS68470 GPIOs > > On Sun, Jun 11, 2017 at 9:09 AM, Rajmohan Mani > wrote: > > This patch adds support for TPS68470 GPIOs. > > There are 7 GPIOs and a few sensor related GPIOs. > > These GPIOs can be requested and configured as appropriate. > > Main points (some I already told in an answer to Sakari's mail): > 1. Consider 2 GPIO chips over 1. I am looking into this. > 2. Fix FIXME(s). Leaving this on, until I see how this can be fixed. > 3. If there is hardware bug we should work around it must be clarified. Ack If this is about initializing the GPIOs with zero, I have removed this code for now. > 4. You missed Linus' comments here (switch to the data pointer inside GPIO > chip and remove platform driver data stuff from the driver). > I have fixed this with v3