From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7BD46C433E1 for ; Tue, 25 Aug 2020 11:40:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 503B02075B for ; Tue, 25 Aug 2020 11:40:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="V8LDzF9P" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729882AbgHYLkF (ORCPT ); Tue, 25 Aug 2020 07:40:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728993AbgHYLi6 (ORCPT ); Tue, 25 Aug 2020 07:38:58 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6B3DC061755; Tue, 25 Aug 2020 04:38:57 -0700 (PDT) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 9193E29E; Tue, 25 Aug 2020 13:38:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1598355529; bh=oP1EjEnIIX7C41Y3YV+hfiXso0su8fK+nrUt1wKEF9Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V8LDzF9P8hldB1tNCUwNJ/7EKxSr62Gp1cWVZMi/+ekcPHd96IW+rWoq5QdRJlTqH dQ0DWxLi6Lzl6uAqGyxMgjAeEx/ru0IdXvNGSXFnSHtZYbvQMxELXOraGf4t8piTKA ZndhWp0G8aMHKXNn/qTcdYqI4v37quU1a+7p0eyo= Date: Tue, 25 Aug 2020 14:38:28 +0300 From: Laurent Pinchart To: Mauro Carvalho Chehab Cc: Dave Airlie , Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , Sam Ravnborg , driverdevel , Daniel Borkmann , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200825113815.GA6767@pendragon.ideasonboard.com> References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> <20200820090326.3f400a15@coco.lan> <20200820100205.GA5962@pendragon.ideasonboard.com> <20200825133025.13f047f0@coco.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200825133025.13f047f0@coco.lan> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mauro, On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote: > Em Tue, 25 Aug 2020 05:29:29 +1000 > Dave Airlie escreveu: > > > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart > > wrote: > > > > > > Hi Mauro, > > > > > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote: > > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote: > > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > > > > > > > > > Based on his history, this driver seems to be originally written > > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > > > > > implementation for FB dev API. > > > > > > > > > > > > > > > > As I need to preserve the original history (with has patches from > > > > > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > > > > > patch applied there. The remaining patches are incremental, > > > > > > > > and port this driver to work with upstream Kernel. > > > > > > > > > > > > > ... > > > > > > > > - Due to legal reasons, I need to preserve the authorship of > > > > > > > > each one responsbile for each patch. So, I need to start from > > > > > > > > the original patch from Kernel 4.4; > > > > > ... > > > > > > > I do acknowledge you need to preserve history and all - > > > > > > > but this patchset is not easy to review. > > > > > > > > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > > > > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > > > > > that contains the history is useful if anyone is interested, but I don't > > > > > > think it's required in mainline. > > > > > > > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > > > > > have on this but preserving the "absolute" history here is actively > > > > > detrimental for review and understanding of the patch set. > > > > > > > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > > > > > lines should be sufficient to provide both atribution credit and DCO > > > > > history. > > > > > > > > I'm not convinced that, from legal standpoint, folding things would > > > > be enough. See, there are at least 3 legal systems involved here > > > > among the different patch authors: > > > > > > > > - civil law; > > > > - common law; > > > > - customary law + common law. > > > > > > > > Merging stuff altogether from different law systems can be problematic, > > > > and trying to discuss this with experienced IP property lawyers will > > > > for sure take a lot of time and efforts. I also bet that different > > > > lawyers will have different opinions, because laws are subject to > > > > interpretation. With that matter I'm not aware of any court rules > > > > with regards to folded patches. So, it sounds to me that folding > > > > patches is something that has yet to be proofed in courts around > > > > the globe. > > > > > > > > At least for US legal system, it sounds that the Country of > > > > origin of a patch is relevant, as they have a concept of > > > > "national technology" that can be subject to export regulations. > > > > > > > > From my side, I really prefer to play safe and stay out of any such > > > > legal discussions. > > > > > > Let's be serious for a moment. If you think there are legal issues in > > > taking GPL-v2.0-only patches and squashing them while retaining > > > authorship information through tags, the Linux kernel if *full* of that. > > > You also routinely modify patches that you commit to the media subsystem > > > to fix "small issues". > > > > > > The country of origin argument makes no sense either, the kernel code > > > base if full of code coming from pretty much all country on the planet. > > > > > > Keeping the patches separate make this hard to review. Please squash > > > them. > > > > I'm inclined to agree with Laurent here. > > > > Patches submitted as GPL-v2 with DCO lines and author names/companies > > should be fine to be squashed and rearranged, > > as long as the DCO and Authorship is kept somewhere in the new patch > > that is applied. > > > > Review is more important here. > > Sorry, but I can't agree that review is more important than to be able > to properly indicate copyrights in a valid way at the legal systems that > it would apply ;-) > > In any case, there's an easy way to make the code easy to review: > I can write the patches against staging (where it is OK to submit > preserving the history) and then add a final patch moving it out > of staging. > > You can then just review the last patch, as it will contain the > entire code on it. > > Another alternative, as I'm already doing with Sam, is for me to > submit the folded code as a reply to 00/xx. You can then just > review the final code, without concerning about how the code reached > there. > > From review point of the view, this will be the same as reviewing > a folded patch, but, from legal standpoint, the entire copyright > chain will be preserved. Let's stop with the legal FUD please. Squashing patches is done routinely in the kernel. If you have evidence this causes legal issues, please bring it up with the TAB or the LF to make this practice stop. Otherwise, please squash this series. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7492C433DF for ; Tue, 25 Aug 2020 11:39:03 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B330E206F0 for ; Tue, 25 Aug 2020 11:39:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="V8LDzF9P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B330E206F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 7CD4E22026; Tue, 25 Aug 2020 11:39:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ubiypcs235h5; Tue, 25 Aug 2020 11:38:58 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by silver.osuosl.org (Postfix) with ESMTP id B1589214E6; Tue, 25 Aug 2020 11:38:58 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id DF5D21BF48D for ; Tue, 25 Aug 2020 11:38:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id DB4F88616A for ; Tue, 25 Aug 2020 11:38:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h42R8E9Zb8sp for ; Tue, 25 Aug 2020 11:38:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 8E07585F3A for ; Tue, 25 Aug 2020 11:38:56 +0000 (UTC) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 9193E29E; Tue, 25 Aug 2020 13:38:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1598355529; bh=oP1EjEnIIX7C41Y3YV+hfiXso0su8fK+nrUt1wKEF9Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V8LDzF9P8hldB1tNCUwNJ/7EKxSr62Gp1cWVZMi/+ekcPHd96IW+rWoq5QdRJlTqH dQ0DWxLi6Lzl6uAqGyxMgjAeEx/ru0IdXvNGSXFnSHtZYbvQMxELXOraGf4t8piTKA ZndhWp0G8aMHKXNn/qTcdYqI4v37quU1a+7p0eyo= Date: Tue, 25 Aug 2020 14:38:28 +0300 From: Laurent Pinchart To: Mauro Carvalho Chehab Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200825113815.GA6767@pendragon.ideasonboard.com> References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> <20200820090326.3f400a15@coco.lan> <20200820100205.GA5962@pendragon.ideasonboard.com> <20200825133025.13f047f0@coco.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200825133025.13f047f0@coco.lan> X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , Sam Ravnborg , driverdevel , Daniel Borkmann , Dave Airlie , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" Hi Mauro, On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote: > Em Tue, 25 Aug 2020 05:29:29 +1000 > Dave Airlie escreveu: > > > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart > > wrote: > > > > > > Hi Mauro, > > > > > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote: > > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote: > > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > > > > > > > > > Based on his history, this driver seems to be originally written > > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > > > > > implementation for FB dev API. > > > > > > > > > > > > > > > > As I need to preserve the original history (with has patches from > > > > > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > > > > > patch applied there. The remaining patches are incremental, > > > > > > > > and port this driver to work with upstream Kernel. > > > > > > > > > > > > > ... > > > > > > > > - Due to legal reasons, I need to preserve the authorship of > > > > > > > > each one responsbile for each patch. So, I need to start from > > > > > > > > the original patch from Kernel 4.4; > > > > > ... > > > > > > > I do acknowledge you need to preserve history and all - > > > > > > > but this patchset is not easy to review. > > > > > > > > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > > > > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > > > > > that contains the history is useful if anyone is interested, but I don't > > > > > > think it's required in mainline. > > > > > > > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > > > > > have on this but preserving the "absolute" history here is actively > > > > > detrimental for review and understanding of the patch set. > > > > > > > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > > > > > lines should be sufficient to provide both atribution credit and DCO > > > > > history. > > > > > > > > I'm not convinced that, from legal standpoint, folding things would > > > > be enough. See, there are at least 3 legal systems involved here > > > > among the different patch authors: > > > > > > > > - civil law; > > > > - common law; > > > > - customary law + common law. > > > > > > > > Merging stuff altogether from different law systems can be problematic, > > > > and trying to discuss this with experienced IP property lawyers will > > > > for sure take a lot of time and efforts. I also bet that different > > > > lawyers will have different opinions, because laws are subject to > > > > interpretation. With that matter I'm not aware of any court rules > > > > with regards to folded patches. So, it sounds to me that folding > > > > patches is something that has yet to be proofed in courts around > > > > the globe. > > > > > > > > At least for US legal system, it sounds that the Country of > > > > origin of a patch is relevant, as they have a concept of > > > > "national technology" that can be subject to export regulations. > > > > > > > > From my side, I really prefer to play safe and stay out of any such > > > > legal discussions. > > > > > > Let's be serious for a moment. If you think there are legal issues in > > > taking GPL-v2.0-only patches and squashing them while retaining > > > authorship information through tags, the Linux kernel if *full* of that. > > > You also routinely modify patches that you commit to the media subsystem > > > to fix "small issues". > > > > > > The country of origin argument makes no sense either, the kernel code > > > base if full of code coming from pretty much all country on the planet. > > > > > > Keeping the patches separate make this hard to review. Please squash > > > them. > > > > I'm inclined to agree with Laurent here. > > > > Patches submitted as GPL-v2 with DCO lines and author names/companies > > should be fine to be squashed and rearranged, > > as long as the DCO and Authorship is kept somewhere in the new patch > > that is applied. > > > > Review is more important here. > > Sorry, but I can't agree that review is more important than to be able > to properly indicate copyrights in a valid way at the legal systems that > it would apply ;-) > > In any case, there's an easy way to make the code easy to review: > I can write the patches against staging (where it is OK to submit > preserving the history) and then add a final patch moving it out > of staging. > > You can then just review the last patch, as it will contain the > entire code on it. > > Another alternative, as I'm already doing with Sam, is for me to > submit the folded code as a reply to 00/xx. You can then just > review the final code, without concerning about how the code reached > there. > > From review point of the view, this will be the same as reviewing > a folded patch, but, from legal standpoint, the entire copyright > chain will be preserved. Let's stop with the legal FUD please. Squashing patches is done routinely in the kernel. If you have evidence this causes legal issues, please bring it up with the TAB or the LF to make this practice stop. Otherwise, please squash this series. -- Regards, Laurent Pinchart _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AB41C433E1 for ; Tue, 25 Aug 2020 11:40:38 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E7CF7206F0 for ; Tue, 25 Aug 2020 11:40:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oYl4v9Qm"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="V8LDzF9P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7CF7206F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=kKoe8IPdu27VTwc9dkAa50oNQfVmxc4aweJFSPXrt/4=; b=oYl4v9Qm1gzN7Y8vZi+NgM8MQ hnyDB4C09oDDIuXKMN7fwQpXdVgo2+1GiLk5XMuamczMN6+MOTQqx7wQJHhlX3gs0pBlt6Xf7knXO GexOkD8KEQGIDfuPIyhnpXacHIVN1utxDL98u685X+L2jCcdswM3wmql+X1iyimlhHCgf6EqqPRwb 1ruMfkJiYQI4aBCFjDKhIQOZiFe10MNuBkmQZo4wlcIFtncn5HzIw03+xyL34zeOpVirhiXS7aokq BBExCBtAt7eyw+u2BLeJ+WbpLWhlvcybwFPui6uSmN90xdjk178JzcDc3JimSO++yS+Sr92Id6KJa ClNuk4FEg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAXI4-0005xC-MF; Tue, 25 Aug 2020 11:39:00 +0000 Received: from perceval.ideasonboard.com ([213.167.242.64]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAXI2-0005vi-3u for linux-arm-kernel@lists.infradead.org; Tue, 25 Aug 2020 11:38:59 +0000 Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 9193E29E; Tue, 25 Aug 2020 13:38:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1598355529; bh=oP1EjEnIIX7C41Y3YV+hfiXso0su8fK+nrUt1wKEF9Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V8LDzF9P8hldB1tNCUwNJ/7EKxSr62Gp1cWVZMi/+ekcPHd96IW+rWoq5QdRJlTqH dQ0DWxLi6Lzl6uAqGyxMgjAeEx/ru0IdXvNGSXFnSHtZYbvQMxELXOraGf4t8piTKA ZndhWp0G8aMHKXNn/qTcdYqI4v37quU1a+7p0eyo= Date: Tue, 25 Aug 2020 14:38:28 +0300 From: Laurent Pinchart To: Mauro Carvalho Chehab Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200825113815.GA6767@pendragon.ideasonboard.com> References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> <20200820090326.3f400a15@coco.lan> <20200820100205.GA5962@pendragon.ideasonboard.com> <20200825133025.13f047f0@coco.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200825133025.13f047f0@coco.lan> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200825_073858_347131_43B879A5 X-CRM114-Status: GOOD ( 47.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , Sam Ravnborg , driverdevel , Daniel Borkmann , Dave Airlie , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mauro, On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote: > Em Tue, 25 Aug 2020 05:29:29 +1000 > Dave Airlie escreveu: > > > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart > > wrote: > > > > > > Hi Mauro, > > > > > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote: > > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote: > > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > > > > > > > > > Based on his history, this driver seems to be originally written > > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > > > > > implementation for FB dev API. > > > > > > > > > > > > > > > > As I need to preserve the original history (with has patches from > > > > > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > > > > > patch applied there. The remaining patches are incremental, > > > > > > > > and port this driver to work with upstream Kernel. > > > > > > > > > > > > > ... > > > > > > > > - Due to legal reasons, I need to preserve the authorship of > > > > > > > > each one responsbile for each patch. So, I need to start from > > > > > > > > the original patch from Kernel 4.4; > > > > > ... > > > > > > > I do acknowledge you need to preserve history and all - > > > > > > > but this patchset is not easy to review. > > > > > > > > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > > > > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > > > > > that contains the history is useful if anyone is interested, but I don't > > > > > > think it's required in mainline. > > > > > > > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > > > > > have on this but preserving the "absolute" history here is actively > > > > > detrimental for review and understanding of the patch set. > > > > > > > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > > > > > lines should be sufficient to provide both atribution credit and DCO > > > > > history. > > > > > > > > I'm not convinced that, from legal standpoint, folding things would > > > > be enough. See, there are at least 3 legal systems involved here > > > > among the different patch authors: > > > > > > > > - civil law; > > > > - common law; > > > > - customary law + common law. > > > > > > > > Merging stuff altogether from different law systems can be problematic, > > > > and trying to discuss this with experienced IP property lawyers will > > > > for sure take a lot of time and efforts. I also bet that different > > > > lawyers will have different opinions, because laws are subject to > > > > interpretation. With that matter I'm not aware of any court rules > > > > with regards to folded patches. So, it sounds to me that folding > > > > patches is something that has yet to be proofed in courts around > > > > the globe. > > > > > > > > At least for US legal system, it sounds that the Country of > > > > origin of a patch is relevant, as they have a concept of > > > > "national technology" that can be subject to export regulations. > > > > > > > > From my side, I really prefer to play safe and stay out of any such > > > > legal discussions. > > > > > > Let's be serious for a moment. If you think there are legal issues in > > > taking GPL-v2.0-only patches and squashing them while retaining > > > authorship information through tags, the Linux kernel if *full* of that. > > > You also routinely modify patches that you commit to the media subsystem > > > to fix "small issues". > > > > > > The country of origin argument makes no sense either, the kernel code > > > base if full of code coming from pretty much all country on the planet. > > > > > > Keeping the patches separate make this hard to review. Please squash > > > them. > > > > I'm inclined to agree with Laurent here. > > > > Patches submitted as GPL-v2 with DCO lines and author names/companies > > should be fine to be squashed and rearranged, > > as long as the DCO and Authorship is kept somewhere in the new patch > > that is applied. > > > > Review is more important here. > > Sorry, but I can't agree that review is more important than to be able > to properly indicate copyrights in a valid way at the legal systems that > it would apply ;-) > > In any case, there's an easy way to make the code easy to review: > I can write the patches against staging (where it is OK to submit > preserving the history) and then add a final patch moving it out > of staging. > > You can then just review the last patch, as it will contain the > entire code on it. > > Another alternative, as I'm already doing with Sam, is for me to > submit the folded code as a reply to 00/xx. You can then just > review the final code, without concerning about how the code reached > there. > > From review point of the view, this will be the same as reviewing > a folded patch, but, from legal standpoint, the entire copyright > chain will be preserved. Let's stop with the legal FUD please. Squashing patches is done routinely in the kernel. If you have evidence this causes legal issues, please bring it up with the TAB or the LF to make this practice stop. Otherwise, please squash this series. -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7D09C433DF for ; Tue, 25 Aug 2020 11:38:55 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9DE54206F0 for ; Tue, 25 Aug 2020 11:38:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="V8LDzF9P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DE54206F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 65A5F6E8EB; Tue, 25 Aug 2020 11:38:54 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by gabe.freedesktop.org (Postfix) with ESMTPS id B2FFD6E8EB for ; Tue, 25 Aug 2020 11:38:52 +0000 (UTC) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 9193E29E; Tue, 25 Aug 2020 13:38:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1598355529; bh=oP1EjEnIIX7C41Y3YV+hfiXso0su8fK+nrUt1wKEF9Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V8LDzF9P8hldB1tNCUwNJ/7EKxSr62Gp1cWVZMi/+ekcPHd96IW+rWoq5QdRJlTqH dQ0DWxLi6Lzl6uAqGyxMgjAeEx/ru0IdXvNGSXFnSHtZYbvQMxELXOraGf4t8piTKA ZndhWp0G8aMHKXNn/qTcdYqI4v37quU1a+7p0eyo= Date: Tue, 25 Aug 2020 14:38:28 +0300 From: Laurent Pinchart To: Mauro Carvalho Chehab Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200825113815.GA6767@pendragon.ideasonboard.com> References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> <20200820090326.3f400a15@coco.lan> <20200820100205.GA5962@pendragon.ideasonboard.com> <20200825133025.13f047f0@coco.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200825133025.13f047f0@coco.lan> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , Sam Ravnborg , driverdevel , Daniel Borkmann , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Mauro, On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote: > Em Tue, 25 Aug 2020 05:29:29 +1000 > Dave Airlie escreveu: > > > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart > > wrote: > > > > > > Hi Mauro, > > > > > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote: > > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote: > > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > > > > > > > > > Based on his history, this driver seems to be originally written > > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > > > > > implementation for FB dev API. > > > > > > > > > > > > > > > > As I need to preserve the original history (with has patches from > > > > > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > > > > > patch applied there. The remaining patches are incremental, > > > > > > > > and port this driver to work with upstream Kernel. > > > > > > > > > > > > > ... > > > > > > > > - Due to legal reasons, I need to preserve the authorship of > > > > > > > > each one responsbile for each patch. So, I need to start from > > > > > > > > the original patch from Kernel 4.4; > > > > > ... > > > > > > > I do acknowledge you need to preserve history and all - > > > > > > > but this patchset is not easy to review. > > > > > > > > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > > > > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > > > > > that contains the history is useful if anyone is interested, but I don't > > > > > > think it's required in mainline. > > > > > > > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > > > > > have on this but preserving the "absolute" history here is actively > > > > > detrimental for review and understanding of the patch set. > > > > > > > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > > > > > lines should be sufficient to provide both atribution credit and DCO > > > > > history. > > > > > > > > I'm not convinced that, from legal standpoint, folding things would > > > > be enough. See, there are at least 3 legal systems involved here > > > > among the different patch authors: > > > > > > > > - civil law; > > > > - common law; > > > > - customary law + common law. > > > > > > > > Merging stuff altogether from different law systems can be problematic, > > > > and trying to discuss this with experienced IP property lawyers will > > > > for sure take a lot of time and efforts. I also bet that different > > > > lawyers will have different opinions, because laws are subject to > > > > interpretation. With that matter I'm not aware of any court rules > > > > with regards to folded patches. So, it sounds to me that folding > > > > patches is something that has yet to be proofed in courts around > > > > the globe. > > > > > > > > At least for US legal system, it sounds that the Country of > > > > origin of a patch is relevant, as they have a concept of > > > > "national technology" that can be subject to export regulations. > > > > > > > > From my side, I really prefer to play safe and stay out of any such > > > > legal discussions. > > > > > > Let's be serious for a moment. If you think there are legal issues in > > > taking GPL-v2.0-only patches and squashing them while retaining > > > authorship information through tags, the Linux kernel if *full* of that. > > > You also routinely modify patches that you commit to the media subsystem > > > to fix "small issues". > > > > > > The country of origin argument makes no sense either, the kernel code > > > base if full of code coming from pretty much all country on the planet. > > > > > > Keeping the patches separate make this hard to review. Please squash > > > them. > > > > I'm inclined to agree with Laurent here. > > > > Patches submitted as GPL-v2 with DCO lines and author names/companies > > should be fine to be squashed and rearranged, > > as long as the DCO and Authorship is kept somewhere in the new patch > > that is applied. > > > > Review is more important here. > > Sorry, but I can't agree that review is more important than to be able > to properly indicate copyrights in a valid way at the legal systems that > it would apply ;-) > > In any case, there's an easy way to make the code easy to review: > I can write the patches against staging (where it is OK to submit > preserving the history) and then add a final patch moving it out > of staging. > > You can then just review the last patch, as it will contain the > entire code on it. > > Another alternative, as I'm already doing with Sam, is for me to > submit the folded code as a reply to 00/xx. You can then just > review the final code, without concerning about how the code reached > there. > > From review point of the view, this will be the same as reviewing > a folded patch, but, from legal standpoint, the entire copyright > chain will be preserved. Let's stop with the legal FUD please. Squashing patches is done routinely in the kernel. If you have evidence this causes legal issues, please bring it up with the TAB or the LF to make this practice stop. Otherwise, please squash this series. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel