From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754543AbcCPJgA (ORCPT ); Wed, 16 Mar 2016 05:36:00 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:16300 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379AbcCPJf5 (ORCPT ); Wed, 16 Mar 2016 05:35:57 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Wed, 16 Mar 2016 02:35:09 -0700 Message-ID: <56E925DC.6000505@nvidia.com> Date: Wed, 16 Mar 2016 14:52:36 +0530 From: Laxman Dewangan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lee Jones CC: Rhyland Klein , Subject: Re: [PATCH] mfd: Fix MACRO for commonly declared MFD cell attributes 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> <20160316084219.GV13692@x1> In-Reply-To: <20160316084219.GV13692@x1> X-Originating-IP: [10.19.65.30] X-ClientProxiedBy: BGMAIL104.nvidia.com (10.25.59.13) To bgmail102.nvidia.com (10.25.59.11) Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 16 March 2016 02:12 PM, Lee Jones wrote: > 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. Thanks, I had sent V9 version of the MAX77620 which used normal un-MACROed version.