[U-Boot] [PATCH 02/60] mmc: tegra: move pad init into MMC driver

[Stephen Warren <swarren@wwwdotorg.org>]

On 04/25/2016 06:14 PM, Tom Rini wrote:
> On Mon, Apr 25, 2016 at 05:34:55PM -0600, Stephen Warren wrote:
>> On 04/25/2016 05:26 PM, Tom Rini wrote:
>>> On Mon, Apr 25, 2016 at 05:11:16PM -0600, Stephen Warren wrote:
>>>> On 04/25/2016 05:05 PM, Tom Rini wrote:
>>>>> On Mon, Apr 25, 2016 at 04:43:34PM -0600, Stephen Warren wrote:
>>>>>> On 04/25/2016 04:37 PM, Tom Rini wrote:
>>>>>>> On Mon, Apr 25, 2016 at 11:52:53PM +0200, Wolfgang Denk wrote:
>>>>>>>> Dear Stephen Warren,
>>>>>>>>
>>>>>>>> In message <571E733A.1060208@wwwdotorg.org> you wrote:
>>>>>>> [snip]
>>>>>>>>> Unfortunately we've (NVIDIA at least) been a little lax making sure the
>>>>>>>>> NVIDIA copyright messages are kept up-to-date when editing files, hence
>>>>>>>>> why this series had to change a lot of them for the first time recently.
>>>>>>>>> If we went back and re-wrote all of git history paying strict attention
>>>>>>>>> to the copyright notice dates and formatting, I imagine the set of
>>>>>>>>> copyright-related changes in this series would be much smaller.
>>>>>>>
>>>>>>> I'm quoting Wolfgang's email here, but, yes, keeping the copyright
>>>>>>> notices correct is important.  Now, what do you mean by would be
>>>>>>> smaller?
>>>>>>
>>>>>> Personally I want to spend my time coding rather than dealing with
>>>>>> licensing. As such, it's easy to forget to update the dates in
>>>>>> copyright notices when changing files, or to put the correct
>>>>>> information into new files when creating new ones (often by just
>>>>>> cutting/pasting some other file with similar issues). If we had done
>>>>>> that 100% correctly in every commit across history, my inclination
>>>>>> is that more files would already have an NVIDIA copyright message,
>>>>>> and/or already have 2016 in the date, and hence this series wouldn't
>>>>>> include an edit to those messages since they'd already be
>>>>>> up-to-date. Still, I have no searched all history to confirm that;
>>>>>> it's just my gut instinct.
>>>>>
>>>>> Right, OK.  So you're saying you may, in some cases, be adding 2016 to
>>>>> files you haven't touched this year yet?
>>>>
>>>> Yes, I'm sure there's a mix.
>>>
>>> OK.  And I assume you're globbing on file paths to check / update?
>>> Doing you can do 'git log --since=YYYY-01-01-YYYY-12-31' to find the
>>> first/last commits in a given year, git diff a..b | diffstat > Y.txt to
>>> get a diffstat and check your numbers vs that.  This doesn't feel like
>>> an undue burden on making sure copyright stuff is year-correct for
>>> last-touch.
>>
>> Well, by "yet" I assumed you mean "before this patch set". There are
>> no changes in the patch set that do nothing but edit/add a copyright
>> notice without making other changes. The only edits to copyrights in
>> this series are because I've edited files for the purpose behind the
>> patch, and then have updated the copyright while doing so.
>>
>> What I did was:
>> a) Make all the changes.
>> b) Go through all the patches with "git rebase -i", get the list of
>> files edited in the patch, and ensure the copyright date reflected
>> the edit made in that patch.
>
> OK.  This should make any quick sanity checks easier, rather than
> harder.  Generate the lists, diffstat your series, for F in series, grep
> -q year-list && echo touched $F;done
>
>> BTW, while code re-org is not the most involved of coding, I don't
>> see a reason to make developers decide legal issues such as what
>> amounts to a change that's large enough to change the copyright
>> date, or add a copyright header. The rule should be simple and
>> unambiguous (edit a file -> change the copyright); anything else is
>> asking for different people to argue over interpretation, which just
>> everybody's wastes time. Let's leave that to lawyers and just deal
>> with code.
>
> I agree in spirit, with a caveat about meeting a significance threshold.
> I think you need to push back on your legal department if they are
> asking that every change requires a copyright notice, regardless of
> length or complexity.  I _cannot_ start having patches conflict because
> the contents are fine but now I have to fixup the copyright notices
> added since the patch was generated,

I'm not sure why. Let's say the two conflicting patches are both 
unambiguously significant works, by two different people/entities. 
Surely there's no issue with the copyright notices both being 
added/updated in that case? If so, then the only difference is the 
volume of conflicts. Volume doesn't seem a great argument since it's not 
a problem with the core issue itself.