linux-kernel - Re: [PATCH 2/2] misc: nirtfeatures: physical interface elements

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] [day] [month] [year] [list]

Message-ID: <20160315160200.GB3216@senary>
Date:	Tue, 15 Mar 2016 11:02:01 -0500
From:	Kyle Roeschley <kyle.roeschley@...com>
To:	Josh Cartwright <joshc@...com>
CC:	<gregkh@...uxfoundation.org>, <arnd@...db.de>,
	<linux-kernel@...r.kernel.org>, <jeff.westfahl@...com>,
	<nathan.sullivan@...com>, <xander.huff@...com>,
	<aaron.rossetto@...com>, <gratian.crisan@...com>
Subject: Re: [PATCH 2/2] misc: nirtfeatures: physical interface elements

On Tue, Mar 15, 2016 at 09:53:27AM -0500, Josh Cartwright wrote:
> Hey Kyle-
> 
> On Mon, Mar 14, 2016 at 04:55:08PM -0500, Kyle Roeschley wrote:
> > From: Gratian Crisan <gratian.crisan@...com>
> 
> From what I understand, this was mostly Aaron's work, so he should get
> authorship.  I could be wrong, though, but you'll want to check.
> 

Correct, that was just 'git format-patch' grabbing the name of the final
committer on our internal repo. I'll clear that up.

> > These changes add support for PIEs (physical interface elements), which
> > are defined as physical elements fixed to a controller/chassis with
> > which a user can interact (e.g. LEDs and switches) and whose meaning
> > is user-defined and implementation-specific.
> [..]
> > ---
> >  drivers/misc/nirtfeatures.c | 753 ++++++++++++++++++++++++++++++++++++++++----
> >  1 file changed, 694 insertions(+), 59 deletions(-)
> 
> This patchset is awkwardly split up, especially because you are removing
> what you are adding in the first patch.  I would suggest coming up with
> a better patch breakdown that doesn't do this, to make it easier on
> reviewers.
> 
> Perhaps, breaking it up into a patchset where each patch implements a
> different class of functionality (leds, input).

Seems reasonable, I'll try to clean this up some.

> 
>   Josh

-- 
Kyle Roeschley
Software Engineer
National Instruments