From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966039AbcCPImb (ORCPT ); Wed, 16 Mar 2016 04:42:31 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:34894 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935021AbcCPImX (ORCPT ); Wed, 16 Mar 2016 04:42:23 -0400 Date: Wed, 16 Mar 2016 08:42:19 +0000 From: Lee Jones To: Laxman Dewangan Cc: Rhyland Klein , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mfd: Fix MACRO for commonly declared MFD cell attributes Message-ID: <20160316084219.GV13692@x1> References: <1455821558-28493-1-git-send-email-rklein@nvidia.com> <20160219085019.GA3410@x1> <56C742C4.4080308@nvidia.com> <56D07ED6.7030607@nvidia.com> <56D43BE1.1080501@nvidia.com> <20160302130828.GB3444@x1> <56E023B2.5020207@nvidia.com> <20160310020439.GR13692@x1> <56E2888D.3010406@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56E2888D.3010406@nvidia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 Mar 2016, Laxman Dewangan wrote: > > On Friday 11 March 2016 02:09 PM, Lee Jones wrote: > >On Wed, 09 Mar 2016, Laxman Dewangan wrote: > >>On Wednesday 02 March 2016 06:38 PM, Lee Jones wrote: > >>>On Mon, 29 Feb 2016, Laxman Dewangan wrote: > >>> > >>>>On Friday 26 February 2016 10:05 PM, Rhyland Klein wrote: > >>>>>Did you not see warnings like this when you compiled the kernel? Did you > >>>>>find a different approach than what I proposed above to deal with it? > >>>>>I'd like to get this in soon so that when the max77620 drivers are all > >>>>>in and using it, it should be functional. > >>>>> > >>>>I think the following change also crash in runtime: > >>>> > >>>>/*** > >>>>commit e60a946f05db2cac857025da6ffb72df48d3be54 > >>>>Author: Lee Jones > >>>> > >>>> mfd: ab8500: Provide a small example using new MFD cell MACROs > >>>> > >>>>***/ > >>>> > >>>>Should we have something MFD_CELL_RES, MFD_CELL_RES_PDATA, > >>>>MFD_CELL_PDATA, for more common user and not to pass the NULL here. > >>>I'll have a re-think about this. > >>Did you get chance to look into this? Probably, I need to send my > >>mfd series once this get fixed before that series applied. > >Nothing is going to happen until v4.6 now. It's too late in the > >release cycle to be making such a significant addition, and I'd like > >the change to sit in -next for a good while before going in. > > > OK, so can I use the local initializations in my max77620 patches > and resend? > Then later we can have cleanups for part only? > > This is because if we get in next release then there is some other > sub modules of the max77620 like clocks, watchdog, power etc which > can go on their subsystem if common header is available. > > Sorry if I am asking too much.. For quick accptance, just submit using the normal un-MACRO'ed structure. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog