From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751842AbdLATuP (ORCPT ); Fri, 1 Dec 2017 14:50:15 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36691 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706AbdLATuN (ORCPT ); Fri, 1 Dec 2017 14:50:13 -0500 X-Google-Smtp-Source: AGs4zMZ4YkZFJlepFv+NVK7bCK9AIsyv9YK5CJFrYY2hbaOLOpWfpoda9hM6QGPpWjZNQFFr6ze6Mp7YQxlkLTAP7Nw= MIME-Version: 1.0 In-Reply-To: <99dd185d-6e5d-f474-90aa-ebee63045c42@caviumnetworks.com> References: <20171129005540.28829-1-david.daney@cavium.com> <20171129005540.28829-4-david.daney@cavium.com> <20171130225333.GI27409@jhogan-linux.mipstec.com> <99dd185d-6e5d-f474-90aa-ebee63045c42@caviumnetworks.com> From: Philippe Ombredanne Date: Fri, 1 Dec 2017 20:49:31 +0100 Message-ID: Subject: Re: [PATCH v4 3/8] MIPS: Octeon: Add a global resource manager. To: David Daney , Greg Kroah-Hartman Cc: Carlos Munoz , David Daney , linux-mips@linux-mips.org, ralf@linux-mips.org, netdev@vger.kernel.org, "David S. Miller" , Rob Herring , Mark Rutland , devel@driverdev.osuosl.org, LKML , "Steven J. Hill" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Andrew Lunn , Florian Fainelli , James Hogan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David, Greg, On Fri, Dec 1, 2017 at 6:42 PM, David Daney wrote: > On 11/30/2017 11:53 PM, Philippe Ombredanne wrote: [...] >>>> --- /dev/null >>>> +++ b/arch/mips/cavium-octeon/resource-mgr.c >>>> @@ -0,0 +1,371 @@ >>>> +// SPDX-License-Identifier: GPL-2.0 >>>> +/* >>>> + * Resource manager for Octeon. >>>> + * >>>> + * This file is subject to the terms and conditions of the GNU General >>>> Public >>>> + * License. See the file "COPYING" in the main directory of this >>>> archive >>>> + * for more details. >>>> + * >>>> + * Copyright (C) 2017 Cavium, Inc. >>>> + */ >> >> >> Since you nicely included an SPDX id, you would not need the >> boilerplate anymore. e.g. these can go alright? > > > They may not be strictly speaking necessary, but I don't think they hurt > anything. Unless there is a requirement to strip out the license text, we > would stick with it as is. I think the requirement is there and that would be much better for everyone: keeping both is redundant and does not bring any value, does it? Instead it kinda removes the benefits of having the SPDX id in the first place IMHO. Furthermore, as there have been already ~12K+ files cleaned up and still over 60K files to go, it would really nice if new files could adopt the new style: this way we will not have to revisit and repatch them in the future. -- Cordially Philippe Ombredanne