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

[Stephen Warren]

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 at 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.

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.