linux-kernel - Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1434799402.19497.47.camel@x220>
Date:	Sat, 20 Jun 2015 13:23:22 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Shobhit Kumar <kumar@...bhit.info>
Cc:	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Shobhit Kumar <shobhit.kumar@...el.com>,
	linux-pwm <linux-pwm@...r.kernel.org>,
	Jani Nikula <jani.nikula@...el.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Alexandre Courbot <gnurou@...il.com>,
	David Airlie <airlied@...ux.ie>,
	Povilas Staniulis <wdmonster@...il.com>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	linux-gpio <linux-gpio@...r.kernel.org>,
	Chih-Wei Huang <cwhuang@...roid-x86.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Lee Jones <lee.jones@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM
 driver

[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/