linux-kernel - Re: [PATCH v2 2/4] mfd: cros_ec: add EC

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]

Date:	Fri, 17 Jun 2016 08:28:23 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Brian Norris <briannorris@...omium.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Olof Johansson <olof@...om.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Brian Norris <computersforpeace@...il.com>,
	linux-pwm <linux-pwm@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Stephen Barber <smbarber@...omium.org>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Benson Leung <bleung@...omium.org>,
	Enric Balletbo <enric.balletbo@...labora.co.uk>,
	Randall Spangler <rspangler@...omium.org>,
	Shawn Nematbakhsh <shawnn@...omium.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Todd Broch <tbroch@...omium.org>,
	Gwendal Grignou <gwendal@...omium.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Subject: Re: [PATCH v2 2/4] mfd: cros_ec: add EC_PWM function definitions

Lee,

On Fri, Jun 17, 2016 at 1:06 AM, Lee Jones <lee.jones@...aro.org> wrote:
>> Probably the reason for all of these non-kernel-isms is that this
>> isn't a kernel file.  From the top of the file:
>>
>>  * NOTE: This file is copied verbatim from the ChromeOS EC Open Source
>>  * project in an attempt to make future updates easy to make.
>>
>> So the source of truth for this file is
>> <https://chromium.googlesource.com/chromiumos/platform/ec/+/master/include/ec_commands.h>.
>>
>> Someone could probably submit a CL to that project to make it a little
>> more kernel-ish and then we'd have to see if the EC team would accept
>> such changes...
>
> Hmmm... that kinda puts me in a difficult position.  Do I except
> non-kernel code, which does not conform to our stands?

What about if Brian made sure to just fully copy the latest version of
"cros_ec_commands.h" from the EC codebase and changed this commit
message to say:

Copy the latest version of "cros_ec_commands.h" from the Chrome OS EC
code base, which is the source of truth for this file.  See
<https://chromium.googlesource.com/chromiumos/platform/ec/+/master/include/ec_commands.h>.

>From the commit message it would be clear that this is an external
file linked into the kernel for convenience.


> Naturally I'd be happier if you could try to make the code more
> 'kernely'.  The practices I mention above are still good ones, even if
> you're not writing kernel specific code.

In general requesting that code from outside the kernel conform to
"kerneldoc" seems like a bit of a stretch.  In general having some
type of parse-able format for comments is nice, but I could see that
in the Chrome OS EC codebase it would be a bit overkill.


Also: it would be awfully strange if we suddenly started changing the
coding convention of this file or we had half the file in one
convention and half in another.  The rest of this file is in EC
convention and it seems sane to keep it that way...


-Doug