David, On Fri, Dec 1, 2017 at 9:01 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote: > On 12/01/2017 11:49 AM, Philippe Ombredanne wrote: >> >> David, Greg, >> >> On Fri, Dec 1, 2017 at 6:42 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> >> 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. >> > > I am happy to follow any style Greg would suggest. There doesn't seem to be > much documentation about how this should be done yet. Thomas (tglx) has already submitted a first series of doc patches a few weeks ago. And AFAIK he might be working on posting the updates soon, whenever his real time clock yields a few cycles away from real time coding work ;) See also these discussions with Linus [1][2][3], Thomas[4] and Greg[5] on this and mostly related topics [1] https://lkml.org/lkml/2017/11/2/715 [2] https://lkml.org/lkml/2017/11/25/125 [3] https://lkml.org/lkml/2017/11/25/133 [4] https://lkml.org/lkml/2017/11/2/805 [5] https://lkml.org/lkml/2017/10/19/165 -- Cordially Philippe Ombredanne _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
