From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754616AbbFTLXj (ORCPT ); Sat, 20 Jun 2015 07:23:39 -0400 Received: from lb1-smtp-cloud2.xs4all.net ([194.109.24.21]:47743 "EHLO lb1-smtp-cloud2.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753150AbbFTLXa (ORCPT ); Sat, 20 Jun 2015 07:23:30 -0400 Message-ID: <1434799402.19497.47.camel@x220> Subject: Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver From: Paul Bolle To: Shobhit Kumar Cc: Paul Gortmaker , Shobhit Kumar , linux-pwm , Jani Nikula , Samuel Ortiz , Alexandre Courbot , David Airlie , Povilas Staniulis , intel-gfx , linux-kernel , dri-devel , linux-gpio , Chih-Wei Huang , Thierry Reding , Daniel Vetter , Lee Jones , Linus Walleij Date: Sat, 20 Jun 2015 13:23:22 +0200 In-Reply-To: References: <1430316005-16480-1-git-send-email-shobhit.kumar@intel.com> <1430316005-16480-7-git-send-email-shobhit.kumar@intel.com> <1430428322.2187.24.camel@x220> <1434652916.2385.124.camel@x220> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Added Paul Gortmaker.] Hi Shobhit, On Fri, 2015-06-19 at 12:16 +0530, Shobhit Kumar wrote: > So what is the exact big problem with this ? The main problem I have is that it's hard to read a submitter's mind. And, I think, in cases like this we need to know if the submitter just made some silly mistake or that the mismatch (between Kconfig type and code) was intentional. So each time such a mismatch is spotted the submitter ought to be asked about it. (I'd guess that one or two new drivers are submitted _each_ day. And these mismatches are quite common. I'd say I receive answers like: - "Oops, yes bool should have been tristate"; or - "Oops, forgot to clean up after noticing tristate didn't work"; or - "I just copy-and-pasted a similar driver, the module stuff isn't actually needed" at least once a week. Not sure, I don't keep track of this stuff.) Furthermore, it appears that Paul Gortmaker is on a mission to, badly summarized, untangle the module and init code. See for instance https://lkml.org/lkml/2015/5/28/809 and https://lkml.org/lkml/2015/5/31/205 . Now, I don't know whether (other) Paul is bothered by these MODULE_* macros. But Paul did submit a series that adds builtin_platform_driver(), see https://lkml.org/lkml/2015/5/10/131 . That new macro ensures built-in only code doesn't have to use module_platform_driver(), which your patch also uses. So perhaps Paul can explain some of the non-obvious issues caused by built-in only code using module specific constructs. > I can anyway shove out these macros to end the discussion. I'd rather convince you than annoy you into doing as I suggested. > BTW whether you buy the argument or not, please do treat yourself > with ice cream for being able to make such a comment. Will do. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Bolle Subject: Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver Date: Sat, 20 Jun 2015 13:23:22 +0200 Message-ID: <1434799402.19497.47.camel@x220> References: <1430316005-16480-1-git-send-email-shobhit.kumar@intel.com> <1430316005-16480-7-git-send-email-shobhit.kumar@intel.com> <1430428322.2187.24.camel@x220> <1434652916.2385.124.camel@x220> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from lb1-smtp-cloud2.xs4all.net ([194.109.24.21]:47743 "EHLO lb1-smtp-cloud2.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753150AbbFTLXa (ORCPT ); Sat, 20 Jun 2015 07:23:30 -0400 In-Reply-To: Sender: linux-gpio-owner@vger.kernel.org List-Id: linux-gpio@vger.kernel.org To: Shobhit Kumar Cc: Paul Gortmaker , Shobhit Kumar , linux-pwm , Jani Nikula , Samuel Ortiz , Alexandre Courbot , David Airlie , Povilas Staniulis , intel-gfx , linux-kernel , dri-devel , linux-gpio , Chih-Wei Huang , Thierry Reding , Daniel Vetter , Lee Jones , Linus Walleij [Added Paul Gortmaker.] Hi Shobhit, On Fri, 2015-06-19 at 12:16 +0530, Shobhit Kumar wrote: > So what is the exact big problem with this ? The main problem I have is that it's hard to read a submitter's mind. And, I think, in cases like this we need to know if the submitter just made some silly mistake or that the mismatch (between Kconfig type and code) was intentional. So each time such a mismatch is spotted the submitter ought to be asked about it. (I'd guess that one or two new drivers are submitted _each_ day. And these mismatches are quite common. I'd say I receive answers like: - "Oops, yes bool should have been tristate"; or - "Oops, forgot to clean up after noticing tristate didn't work"; or - "I just copy-and-pasted a similar driver, the module stuff isn't actually needed" at least once a week. Not sure, I don't keep track of this stuff.) Furthermore, it appears that Paul Gortmaker is on a mission to, badly summarized, untangle the module and init code. See for instance https://lkml.org/lkml/2015/5/28/809 and https://lkml.org/lkml/2015/5/31/205 . Now, I don't know whether (other) Paul is bothered by these MODULE_* macros. But Paul did submit a series that adds builtin_platform_driver(), see https://lkml.org/lkml/2015/5/10/131 . That new macro ensures built-in only code doesn't have to use module_platform_driver(), which your patch also uses. So perhaps Paul can explain some of the non-obvious issues caused by built-in only code using module specific constructs. > I can anyway shove out these macros to end the discussion. I'd rather convince you than annoy you into doing as I suggested. > BTW whether you buy the argument or not, please do treat yourself > with ice cream for being able to make such a comment. Will do. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in