linux-kernel - Re: [RESEND PATCH v7 1/1] platform: Add driver for RAVE Supervisory Processor

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 24 Oct 2017 17:13:25 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Johan Hovold <johan@...nel.org>,
        Andrey Smirnov <andrew.smirnov@...il.com>,
        linux-kernel@...r.kernel.org, cphealy@...il.com,
        Lucas Stach <l.stach@...gutronix.de>,
        Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        Lee Jones <lee.jones@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RESEND PATCH v7 1/1] platform: Add driver for RAVE Supervisory
 Processor

On Mon, Oct 23, 2017 at 11:30:54AM +0200, Pavel Machek wrote:
> Hi!
> 
> > >  drivers/platform/Kconfig        |   2 +
> > >  drivers/platform/Makefile       |   1 +
> > >  drivers/platform/rave/Kconfig   |  26 ++
> > >  drivers/platform/rave/Makefile  |   1 +
> > >  drivers/platform/rave/rave-sp.c | 677 ++++++++++++++++++++++++++++++++++++++++
> > 
> > First of all, why do these live in drivers/platform and why don't use
> > the mfd subsystem to implement this driver (instead of rolling your own
> > mfd-implementation)?
> 
> Sending contributors around like this is quite uncool.

Asking questions when things are done in unexpected ways is part of the
review process, and the backstory here wasn't documented in the patch or
cover letter.

> 1st, it should not matter much in which directory the driver lives.
> 
> 2nd, there's no reasonable way for contributor to proceed if he gets
> "stuck" between two maintainers.
> 
> Can you discuss with MFD maintainers, and provide clear guidance?

Seems we all agree this driver belongs in mfd now.

Johan