Re: [PATCH v4 3/8] MIPS: Octeon: Add a global resource manager.

[David Daney <ddaney@caviumnetworks.com>]

On 12/01/2017 12:41 PM, Philippe Ombredanne wrote:
> David,
>
> On Fri, Dec 1, 2017 at 9:01 PM, David Daney <ddaney@caviumnetworks.com> 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@caviumnetworks.com>
> > > 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
OK, you convinced me.

Thanks,
David