linux-kernel - Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

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:	Sun, 27 Oct 2013 08:54:08 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Steven Newbury <steve@...wbury.org.uk>
Cc:	linux-kernel@...r.kernel.org, Naren Sankar <nsankar@...adcom.com>,
	Jarod Wilson <jarod@...sonet.com>,
	Scott Davilla <davilla@....com>,
	Manu Abraham <abraham.manu@...il.com>
Subject: Re: [PATCH] staging: Merge Crystal HD driver with linuxtv.org

On Sun, Oct 27, 2013 at 04:27:23PM +0000, Steven Newbury wrote:
> The in-kernel staging version and upstream diverged in Jan 2010,
> whilst the in-kernel version has been kept up to date with kernel
> changes, both have recieved some clean ups and bug fixes, upstream
> has also added support for new cards, particularly BCM70015 which
> is now a much more common device than the original BCM70012 and
> is currently available for purchase.
> 
> In addition to the changes below, I've applied all the relevant
> modifications applied to the in-kernel version to the new code
> introduced from upstream, in particular the removal of typedefs and
> unified header handling.
> 
> Quite a lot of the code churn relates to upstream commit
> 317dbd6dda65b4177627d6417b762c287cefa0e7 (crystalhd: nuke BCMLOG
> macros, use std dev_foo ones), I considered stripping these changes
> out and making them a separate patch but decided to stay as close as
> possible to the state of the current linuxtv.org codebase.
> 
> Unfortunately, AFAIK, it's not possible to simply merge the upstream
> git history since the upstream code isn't in a kernel tree structure,
> and isn't even in a simple directory, but includes a script to
> convert the external module into a staging tree driver which I used
> to create a reference tree.  I had to then manually merge both
> versions and fix code conflicts.
> 
> It does now successfully detect and initialise a BCM70015 bought
> last week from Amazon.  It is currently untested on the original
> BCM70012.
> 
> Signed-off-by: Steven Newbury <steve@...wbury.org.uk>

Any reason why you didn't send this to me, the staging tree maintainer?

And I can't take a giant patch like this, it's a mess.  Why not send me
a series of patches that sync things up, like you detail in the odd
changelog entries you show below?

And these patches do a lot of new work to the driver, I'd rather see it
get fixed up properly and moved out of staging first, before adding new
support to it, otherwise why is it in staging at all?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/