[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131027155408.GA22705@kroah.com>
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/
Powered by blists - more mailing lists