[GIT PULL] at91: fixes for 3.19 #1 (bis)

[GIT PULL] at91: fixes for 3.19 #1 (bis)

[Nicolas Ferre]

Arnd, Olof, Kevin,

This is the rebase of my previous pull-request on top of 3.19-rc1. As said at
the time of my early messages, I was waiting for the arm-soc *and* pinctrl
material to reach Linus T.'s tree before sending this pull-request. In fact
this sequence was needed for the gpio header removal. The little patch about
#include deletion just follows an earlier merge conflict in arm-soc tree: I was
also waiting for this moment before sending the definitive fix, just to be
sure.

In comparison with the previous pull-request, I also added a tiny correction of
the sama5d4.dtsi timer entry. All the rest is pretty straightforward.

Thanks, best regards,

The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:

  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git tags/at91-fixes

for you to fetch changes up to 0e049c66ebf56a415cadd6c593b7ee0a2cb9d19d:

  ARM: at91/dt: sama5d4: fix the timer reg length (2015-01-05 11:07:14 +0100)

----------------------------------------------------------------
First fixes batch for AT91 on 3.19 folowing The big cleanup:
- removal of unused Kconfig RTC options
- GPIO header file is now in same directory as the pinctrl driver
- little fix on #includes
- removal of DEBUG_LL from the sama5 common defconfig
- little fix of reg size in sama5d4.dtsi

----------------------------------------------------------------
Bo Shen (1):
      ARM: at91/dt: sama5d4: fix the timer reg length

Boris Brezillon (1):
      ARM: at91: remove useless header file includes

Maxime Ripard (1):
      ARM: at91/config: sama5: Remove DEBUG_LL

Nicolas Ferre (2):
      rtc: at91/Kconfig: remove useless options
      ARM: at91: remove unneeded header file

 arch/arm/boot/dts/sama5d4.dtsi             |  2 +-
 arch/arm/configs/sama5_defconfig           |  2 -
 arch/arm/mach-at91/at91sam9g45.c           |  1 -
 arch/arm/mach-at91/at91sam9rl.c            |  1 -
 arch/arm/mach-at91/include/mach/at91_pio.h | 80 ------------------------------
 drivers/rtc/Kconfig                        | 28 -----------
 6 files changed, 1 insertion(+), 113 deletions(-)
 delete mode 100644 arch/arm/mach-at91/include/mach/at91_pio.h

-- 
Nicolas Ferre

[GIT PULL] at91: fixes for 3.19 #1 (bis)

[Olof Johansson]

On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> This is the rebase of my previous pull-request on top of 3.19-rc1. As said at
> the time of my early messages, I was waiting for the arm-soc *and* pinctrl
> material to reach Linus T.'s tree before sending this pull-request. In fact
> this sequence was needed for the gpio header removal. The little patch about
> #include deletion just follows an earlier merge conflict in arm-soc tree: I was
> also waiting for this moment before sending the definitive fix, just to be
> sure.
> 
> In comparison with the previous pull-request, I also added a tiny correction of
> the sama5d4.dtsi timer entry. All the rest is pretty straightforward.
> 
> Thanks, best regards,
> 
> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
> 
>   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git tags/at91-fixes
> 
> for you to fetch changes up to 0e049c66ebf56a415cadd6c593b7ee0a2cb9d19d:
> 
>   ARM: at91/dt: sama5d4: fix the timer reg length (2015-01-05 11:07:14 +0100)
> 
> ----------------------------------------------------------------
> First fixes batch for AT91 on 3.19 folowing The big cleanup:
> - removal of unused Kconfig RTC options
> - GPIO header file is now in same directory as the pinctrl driver
> - little fix on #includes
> - removal of DEBUG_LL from the sama5 common defconfig
> - little fix of reg size in sama5d4.dtsi
> 
> ----------------------------------------------------------------
> Bo Shen (1):
>       ARM: at91/dt: sama5d4: fix the timer reg length

This is the only fix among these patches, isn't it? The others seem to
be code removals/cleanups better targeted for 3.20, as far as I can tell.


-Olof

[GIT PULL] at91: fixes for 3.19 #1 (bis)

[Nicolas Ferre]

Le 08/01/2015 23:41, Olof Johansson a ?crit :
> On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
>> Arnd, Olof, Kevin,
>>
>> This is the rebase of my previous pull-request on top of 3.19-rc1. As said at
>> the time of my early messages, I was waiting for the arm-soc *and* pinctrl
>> material to reach Linus T.'s tree before sending this pull-request. In fact
>> this sequence was needed for the gpio header removal. The little patch about
>> #include deletion just follows an earlier merge conflict in arm-soc tree: I was
>> also waiting for this moment before sending the definitive fix, just to be
>> sure.
>>
>> In comparison with the previous pull-request, I also added a tiny correction of
>> the sama5d4.dtsi timer entry. All the rest is pretty straightforward.
>>
>> Thanks, best regards,
>>
>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>
>>   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git tags/at91-fixes
>>
>> for you to fetch changes up to 0e049c66ebf56a415cadd6c593b7ee0a2cb9d19d:
>>
>>   ARM: at91/dt: sama5d4: fix the timer reg length (2015-01-05 11:07:14 +0100)
>>
>> ----------------------------------------------------------------
>> First fixes batch for AT91 on 3.19 folowing The big cleanup:
>> - removal of unused Kconfig RTC options
>> - GPIO header file is now in same directory as the pinctrl driver
>> - little fix on #includes
>> - removal of DEBUG_LL from the sama5 common defconfig
>> - little fix of reg size in sama5d4.dtsi
>>
>> ----------------------------------------------------------------
>> Bo Shen (1):
>>       ARM: at91/dt: sama5d4: fix the timer reg length
> 
> This is the only fix among these patches, isn't it? The others seem to
> be code removals/cleanups better targeted for 3.20, as far as I can tell.

Well, this is why I sent the first version of this pull-request very
early in the process. I didn't have the possibility to re-send it
earlier on top of -rc1 until this pull-request.

For me, the remaining of a dead Kconfig option, some issues with
DEGUG_LL and to a lesser extend the remaining of dead code are worth
cleaning now. I do have more cleanup patches to come in 3.20, but
waiting more for this simple material to be included is IMHO not
necessary...

I may have some more fixes remaining for 3.19 and will be cautious about
their nature.


Bye,
-- 
Nicolas Ferre

[GIT PULL] at91: fixes for 3.19 #1 (bis)

[Olof Johansson]

On Fri, Jan 09, 2015 at 10:02:50AM +0100, Nicolas Ferre wrote:
> Le 08/01/2015 23:41, Olof Johansson a ?crit :
> > On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
> >> Arnd, Olof, Kevin,
> >>
> >> This is the rebase of my previous pull-request on top of 3.19-rc1. As said at
> >> the time of my early messages, I was waiting for the arm-soc *and* pinctrl
> >> material to reach Linus T.'s tree before sending this pull-request. In fact
> >> this sequence was needed for the gpio header removal. The little patch about
> >> #include deletion just follows an earlier merge conflict in arm-soc tree: I was
> >> also waiting for this moment before sending the definitive fix, just to be
> >> sure.
> >>
> >> In comparison with the previous pull-request, I also added a tiny correction of
> >> the sama5d4.dtsi timer entry. All the rest is pretty straightforward.
> >>
> >> Thanks, best regards,
> >>
> >> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
> >>
> >>   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git tags/at91-fixes
> >>
> >> for you to fetch changes up to 0e049c66ebf56a415cadd6c593b7ee0a2cb9d19d:
> >>
> >>   ARM: at91/dt: sama5d4: fix the timer reg length (2015-01-05 11:07:14 +0100)
> >>
> >> ----------------------------------------------------------------
> >> First fixes batch for AT91 on 3.19 folowing The big cleanup:
> >> - removal of unused Kconfig RTC options
> >> - GPIO header file is now in same directory as the pinctrl driver
> >> - little fix on #includes
> >> - removal of DEBUG_LL from the sama5 common defconfig
> >> - little fix of reg size in sama5d4.dtsi
> >>
> >> ----------------------------------------------------------------
> >> Bo Shen (1):
> >>       ARM: at91/dt: sama5d4: fix the timer reg length
> > 
> > This is the only fix among these patches, isn't it? The others seem to
> > be code removals/cleanups better targeted for 3.20, as far as I can tell.
> 
> Well, this is why I sent the first version of this pull-request very
> early in the process. I didn't have the possibility to re-send it
> earlier on top of -rc1 until this pull-request.
> 
> For me, the remaining of a dead Kconfig option, some issues with
> DEGUG_LL and to a lesser extend the remaining of dead code are worth
> cleaning now. I do have more cleanup patches to come in 3.20, but
> waiting more for this simple material to be included is IMHO not
> necessary...
> 
> I may have some more fixes remaining for 3.19 and will be cautious about
> their nature.

I'm a bit confused -- I said this branch isn't actually a fixes branch so we
can't merge it for 3.19, but there is _one_ patch from it that looks like it
should go in.

It's not really about whether the material is simple or not -- all maintainers
need to keep focus on only sending up fixes during the -rc series. Sometimes we
pick up a cleanup or two for -rc2 or so, but the time for that for 3.19 is past
us.

Since you mention that you have more fixes coming (why hold off on them?), do
you want me to cherry-pick over that one fix to our fixes branch, or can you
queue it with the other fixes when you send them up?


-Olof

[GIT PULL] at91: fixes for 3.19 #1 (bis)

[Nicolas Ferre]

Le 11/01/2015 22:12, Olof Johansson a ?crit :
> On Fri, Jan 09, 2015 at 10:02:50AM +0100, Nicolas Ferre wrote:
>> Le 08/01/2015 23:41, Olof Johansson a ?crit :
>>> On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
>>>> Arnd, Olof, Kevin,
>>>>
>>>> This is the rebase of my previous pull-request on top of 3.19-rc1. As said at
>>>> the time of my early messages, I was waiting for the arm-soc *and* pinctrl
>>>> material to reach Linus T.'s tree before sending this pull-request. In fact
>>>> this sequence was needed for the gpio header removal. The little patch about
>>>> #include deletion just follows an earlier merge conflict in arm-soc tree: I was
>>>> also waiting for this moment before sending the definitive fix, just to be
>>>> sure.
>>>>
>>>> In comparison with the previous pull-request, I also added a tiny correction of
>>>> the sama5d4.dtsi timer entry. All the rest is pretty straightforward.
>>>>
>>>> Thanks, best regards,
>>>>
>>>> The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
>>>>
>>>>   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git tags/at91-fixes
>>>>
>>>> for you to fetch changes up to 0e049c66ebf56a415cadd6c593b7ee0a2cb9d19d:
>>>>
>>>>   ARM: at91/dt: sama5d4: fix the timer reg length (2015-01-05 11:07:14 +0100)
>>>>
>>>> ----------------------------------------------------------------
>>>> First fixes batch for AT91 on 3.19 folowing The big cleanup:
>>>> - removal of unused Kconfig RTC options
>>>> - GPIO header file is now in same directory as the pinctrl driver
>>>> - little fix on #includes
>>>> - removal of DEBUG_LL from the sama5 common defconfig
>>>> - little fix of reg size in sama5d4.dtsi
>>>>
>>>> ----------------------------------------------------------------
>>>> Bo Shen (1):
>>>>       ARM: at91/dt: sama5d4: fix the timer reg length
>>>
>>> This is the only fix among these patches, isn't it? The others seem to
>>> be code removals/cleanups better targeted for 3.20, as far as I can tell.
>>
>> Well, this is why I sent the first version of this pull-request very
>> early in the process. I didn't have the possibility to re-send it
>> earlier on top of -rc1 until this pull-request.
>>
>> For me, the remaining of a dead Kconfig option, some issues with
>> DEGUG_LL and to a lesser extend the remaining of dead code are worth
>> cleaning now. I do have more cleanup patches to come in 3.20, but
>> waiting more for this simple material to be included is IMHO not
>> necessary...
>>
>> I may have some more fixes remaining for 3.19 and will be cautious about
>> their nature.
> 
> I'm a bit confused -- I said this branch isn't actually a fixes branch so we
> can't merge it for 3.19, but there is _one_ patch from it that looks like it
> should go in.
> 
> It's not really about whether the material is simple or not -- all maintainers
> need to keep focus on only sending up fixes during the -rc series. Sometimes we
> pick up a cleanup or two for -rc2 or so, but the time for that for 3.19 is past
> us.
> 
> Since you mention that you have more fixes coming (why hold off on them?), do
> you want me to cherry-pick over that one fix to our fixes branch, or can you
> queue it with the other fixes when you send them up?

Fair enough, I build a new "at91: fixes for 3.19 #1 (ter)" with tree
more patches right now.

Thanks, bye.
-- 
Nicolas Ferre

[GIT PULL] at91: fixes for 3.19 #1 (bis)

[Arnd Bergmann]

On Monday 12 January 2015 16:08:14 Nicolas Ferre wrote:
> Le 11/01/2015 22:12, Olof Johansson a ?crit :
> > On Fri, Jan 09, 2015 at 10:02:50AM +0100, Nicolas Ferre wrote:
> >> Le 08/01/2015 23:41, Olof Johansson a ?crit :
> >>> On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
> >>>
> >>> This is the only fix among these patches, isn't it? The others seem to
> >>> be code removals/cleanups better targeted for 3.20, as far as I can tell.
> >>
> >> Well, this is why I sent the first version of this pull-request very
> >> early in the process. I didn't have the possibility to re-send it
> >> earlier on top of -rc1 until this pull-request.

I think this was a bit of a communication problem. I thought about
applying the first pull request you sent for this, but then Kevin
commented that it would be better to rebase it on top of -rc1.
That made sense at the time, except then we all got caught by
surprise by Christmas and suddenly it was -rc4 ;-)

> > Since you mention that you have more fixes coming (why hold off on them?), do
> > you want me to cherry-pick over that one fix to our fixes branch, or can you
> > queue it with the other fixes when you send them up?
> 
> Fair enough, I build a new "at91: fixes for 3.19 #1 (ter)" with tree
> more patches right now.

This seems for the best now. This kind of late cleanup that depends on
multiple branches going in first happens occasionally and it's never
nice whichever way you try to handle it.

The only recommendation I have for the future is to discuss the merge
strategy with us before the merge window instead of holding back patches
that have other dependencies. I don't really mind merging them as a
late branch into -rc1 if I know about them, but we should never plan
to merge any non-bugfix patches later than -rc2.

	Arnd

[GIT PULL] at91: fixes for 3.19 #1 (bis)

[Nicolas Ferre]

Le 12/01/2015 16:59, Arnd Bergmann a ?crit :
> On Monday 12 January 2015 16:08:14 Nicolas Ferre wrote:
>> Le 11/01/2015 22:12, Olof Johansson a ?crit :
>>> On Fri, Jan 09, 2015 at 10:02:50AM +0100, Nicolas Ferre wrote:
>>>> Le 08/01/2015 23:41, Olof Johansson a ?crit :
>>>>> On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
>>>>>
>>>>> This is the only fix among these patches, isn't it? The others seem to
>>>>> be code removals/cleanups better targeted for 3.20, as far as I can tell.
>>>>
>>>> Well, this is why I sent the first version of this pull-request very
>>>> early in the process. I didn't have the possibility to re-send it
>>>> earlier on top of -rc1 until this pull-request.
> 
> I think this was a bit of a communication problem. I thought about
> applying the first pull request you sent for this, but then Kevin
> commented that it would be better to rebase it on top of -rc1.
> That made sense at the time, except then we all got caught by
> surprise by Christmas and suddenly it was -rc4 ;-)

Exactly, by surprise like every year ;-)

>>> Since you mention that you have more fixes coming (why hold off on them?), do
>>> you want me to cherry-pick over that one fix to our fixes branch, or can you
>>> queue it with the other fixes when you send them up?
>>
>> Fair enough, I build a new "at91: fixes for 3.19 #1 (ter)" with tree
>> more patches right now.
> 
> This seems for the best now. This kind of late cleanup that depends on
> multiple branches going in first happens occasionally and it's never
> nice whichever way you try to handle it.
> 
> The only recommendation I have for the future is to discuss the merge
> strategy with us before the merge window instead of holding back patches
> that have other dependencies. I don't really mind merging them as a
> late branch into -rc1 if I know about them, but we should never plan
> to merge any non-bugfix patches later than -rc2.

Sure. I'll try to do better next time.
I began to create the at91-3.20-cleanup branch with this late material
and all will be fine anyway.

Thanks, bye.
-- 
Nicolas Ferre