[GIT PULL] i.MX clock fixes for v3.8

[GIT PULL] i.MX clock fixes for v3.8

[Sascha Hauer]

Hi Arnd, Olof,

Please pull these two fixes for v3.8

Sascha

The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7:

  Linux 3.8-rc6 (2013-02-01 12:08:14 +1100)

are available in the git repository at:

  git://git.pengutronix.de/git/imx/linux-2.6.git tags/arm-imx-clk-fixes

for you to fetch changes up to 4b526ca5f627188425184a22ed46c91baa602d43:

  ARM: i.MX25: clk: parent per5_clk to AHB clock (2013-02-05 10:54:35 +0100)

----------------------------------------------------------------
ARM: i.MX: clock fixes

- fix wrong timer clock on i.MX25 leading to strange timing inconsistencies
- fix SPI clocks for i.MX27

----------------------------------------------------------------
Gwenhael Goavec-Merou (1):
      ARM: imx27: clk-imx27: SPI: Rename IPG clock and add PER clock

Steffen Trumtrar (1):
      ARM: i.MX25: clk: parent per5_clk to AHB clock

 arch/arm/mach-imx/clk-imx25.c |    3 +++
 arch/arm/mach-imx/clk-imx27.c |    9 ++++++---
 2 files changed, 9 insertions(+), 3 deletions(-)
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[GIT PULL] i.MX clock fixes for v3.8

[Russell King - ARM Linux]

On Tue, Feb 05, 2013 at 10:58:44AM +0100, Sascha Hauer wrote:
> Hi Arnd, Olof,
> 
> Please pull these two fixes for v3.8

If you haven't heard, Linus wants each and every patch going into v3.8
meeting this criteria:

       fix major security issues, big user-reported regressions, or nasty
       oopses.

and individually justified:

       So think twice - or thrice - before sending me patches or a pull
       request for -rc7. You need to have some seriously good reasons for
       doing so, and you need to state those reasons very clearly. And I
       don't just mean for the pull request in general, I mean for every
       single patch in it.
...
       In other words, "It fixes a bug" just isn't good enough. The bug needs
       to be something that actually matters.

[GIT PULL] i.MX clock fixes for v3.8

[Sascha Hauer]

On Tue, Feb 05, 2013 at 11:08:04AM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 05, 2013 at 10:58:44AM +0100, Sascha Hauer wrote:
> > Hi Arnd, Olof,
> > 
> > Please pull these two fixes for v3.8
> 
> If you haven't heard, Linus wants each and every patch going into v3.8
> meeting this criteria:
> 
>        fix major security issues, big user-reported regressions, or nasty
>        oopses.
> 
> and individually justified:
> 
>        So think twice - or thrice - before sending me patches or a pull
>        request for -rc7. You need to have some seriously good reasons for
>        doing so, and you need to state those reasons very clearly. And I
>        don't just mean for the pull request in general, I mean for every
>        single patch in it.
> ...
>        In other words, "It fixes a bug" just isn't good enough. The bug needs
>        to be something that actually matters.

At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a
regression that causes nasty oopses. Admittedly, it wasn't introduced in
the last merge window and the board requiring the fix needs out of tree
patches.

I'm fine with these going into v3.9 and waiting for the first stable
patch to get the fix for the above.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[GIT PULL] i.MX clock fixes for v3.8

[Arnd Bergmann]

On Tuesday 05 February 2013, Sascha Hauer wrote:
> >        So think twice - or thrice - before sending me patches or a pull
> >        request for -rc7. You need to have some seriously good reasons for
> >        doing so, and you need to state those reasons very clearly. And I
> >        don't just mean for the pull request in general, I mean for every
> >        single patch in it.
> > ...
> >        In other words, "It fixes a bug" just isn't good enough. The bug needs
> >        to be something that actually matters.
> 
> At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a
> regression that causes nasty oopses. Admittedly, it wasn't introduced in
> the last merge window and the board requiring the fix needs out of tree
> patches.
> 
> I'm fine with these going into v3.9 and waiting for the first stable
> patch to get the fix for the above.

My rules is usually: if it's important enough to have it backported
into a stable kernel, then it's also important enough to get sent
at any time during the bug fix phase.

The patch you  mentioned certainly fits that category. The other one
might as well, but the patch description does not actually say what
the impact of the bug is, so it is hard to tell.

	Arnd

[GIT PULL] i.MX clock fixes for v3.8

[Russell King - ARM Linux]

On Tue, Feb 05, 2013 at 01:12:11PM +0000, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Sascha Hauer wrote:
> > >        So think twice - or thrice - before sending me patches or a pull
> > >        request for -rc7. You need to have some seriously good reasons for
> > >        doing so, and you need to state those reasons very clearly. And I
> > >        don't just mean for the pull request in general, I mean for every
> > >        single patch in it.
> > > ...
> > >        In other words, "It fixes a bug" just isn't good enough. The bug needs
> > >        to be something that actually matters.
> > 
> > At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a
> > regression that causes nasty oopses. Admittedly, it wasn't introduced in
> > the last merge window and the board requiring the fix needs out of tree
> > patches.
> > 
> > I'm fine with these going into v3.9 and waiting for the first stable
> > patch to get the fix for the above.
> 
> My rules is usually: if it's important enough to have it backported
> into a stable kernel, then it's also important enough to get sent
> at any time during the bug fix phase.
> 
> The patch you  mentioned certainly fits that category. The other one
> might as well, but the patch description does not actually say what
> the impact of the bug is, so it is hard to tell.

Look at what Linus is saying.  Too much stuff went into -rc6.  He doesn't
want that happening for -rc7.  He wants -rc7 to be really tiny, like
almost _no_ changes.  Look at the description about what he wants to
see: he doesn't want to see user visible regressions.  He wants to see
_big_ user visible regressions only.

Also look at what he's saying wrt describing _every_ _single_ _patch_ in
your pull request with a justification why it's there.  Can you do this
for every patch you have planned to push?  Do you have sufficient
information from those sending you these pull requests for fixes to v3.8
to do that?  If not, you probably shouldn't be pulling them with a view
to sending them to Linus (unless you wish to be flamed.)

I certainly can't with the three patches I had queued for fixes before
-rc6.  They may be fixing problems which cause a few platforms not to
boot or oops at boot, but I can't justify them against what Linus has
said.  So I'm going to wait for the next merge window and put them in
with a stable CC.  There's more patches like that post-rc6: there's one
which fixes an obscure problem with 'make' which occurs with 2G:2G VM
split.  But I'm not pushing that one either because it's not a _big_
enough problem (it's only had _one_ user report it.)  One user is not
sufficient justification.

[GIT PULL] i.MX clock fixes for v3.8

[Olof Johansson]

On Tue, Feb 05, 2013 at 01:27:59PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 05, 2013 at 01:12:11PM +0000, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Sascha Hauer wrote:
> > > >        So think twice - or thrice - before sending me patches or a pull
> > > >        request for -rc7. You need to have some seriously good reasons for
> > > >        doing so, and you need to state those reasons very clearly. And I
> > > >        don't just mean for the pull request in general, I mean for every
> > > >        single patch in it.
> > > > ...
> > > >        In other words, "It fixes a bug" just isn't good enough. The bug needs
> > > >        to be something that actually matters.
> > > 
> > > At least 'ARM: i.MX25: clk: parent per5_clk to AHB clock' is a
> > > regression that causes nasty oopses. Admittedly, it wasn't introduced in
> > > the last merge window and the board requiring the fix needs out of tree
> > > patches.
> > > 
> > > I'm fine with these going into v3.9 and waiting for the first stable
> > > patch to get the fix for the above.
> > 
> > My rules is usually: if it's important enough to have it backported
> > into a stable kernel, then it's also important enough to get sent
> > at any time during the bug fix phase.
> > 
> > The patch you  mentioned certainly fits that category. The other one
> > might as well, but the patch description does not actually say what
> > the impact of the bug is, so it is hard to tell.
> 
> Look at what Linus is saying.  Too much stuff went into -rc6.  He doesn't
> want that happening for -rc7.  He wants -rc7 to be really tiny, like
> almost _no_ changes.  Look at the description about what he wants to
> see: he doesn't want to see user visible regressions.  He wants to see
> _big_ user visible regressions only.
> 
> Also look at what he's saying wrt describing _every_ _single_ _patch_ in
> your pull request with a justification why it's there.  Can you do this
> for every patch you have planned to push?  Do you have sufficient
> information from those sending you these pull requests for fixes to v3.8
> to do that?  If not, you probably shouldn't be pulling them with a view
> to sending them to Linus (unless you wish to be flamed.)
> 
> I certainly can't with the three patches I had queued for fixes before
> -rc6.  They may be fixing problems which cause a few platforms not to
> boot or oops at boot, but I can't justify them against what Linus has
> said.  So I'm going to wait for the next merge window and put them in
> with a stable CC.  There's more patches like that post-rc6: there's one
> which fixes an obscure problem with 'make' which occurs with 2G:2G VM
> split.  But I'm not pushing that one either because it's not a _big_
> enough problem (it's only had _one_ user report it.)  One user is not
> sufficient justification.

Yeah, I was just looking at my queue here (and then came upon this thread).
>From what we have queued up right now in arm-soc fixes, I don't see anything
that _truly_ needs to go in for 3.8.

If someone feels differently, let me know (with a very solid motivation) and
I will consider sending it up. But right now I am likely going to fold the
'fixes' branch into 'fixes-non-critical' for 3.9 instead.


-Olof

[GIT PULL] i.MX clock fixes for v3.8

[Arnd Bergmann]

On Tuesday 05 February 2013 10:44:19 Olof Johansson wrote:
> 
> Yeah, I was just looking at my queue here (and then came upon this thread).
> From what we have queued up right now in arm-soc fixes, I don't see anything
> that _truly_ needs to go in for 3.8.
> 
> If someone feels differently, let me know (with a very solid motivation) and
> I will consider sending it up. But right now I am likely going to fold the
> 'fixes' branch into 'fixes-non-critical' for 3.9 instead.

I was going to put the Samsung fixes for the new bintutils in, but I suppose
that can wait until 3.9, given that it has always been broken. Probably
-stable material though.

	Arnd

[GIT PULL] i.MX clock fixes for v3.8

[Olof Johansson]

On Tue, Feb 5, 2013 at 5:27 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> There's more patches like that post-rc6: there's one
> which fixes an obscure problem with 'make' which occurs with 2G:2G VM
> split.  But I'm not pushing that one either because it's not a _big_
> enough problem (it's only had _one_ user report it.)  One user is not
> sufficient justification.

Can you please make sure that one is marked for stable though? We're
running Chrome OS in 2:2 on ARM, and we're likely going to move to 3.8
at some point.


-Olof

[GIT PULL] i.MX clock fixes for v3.8

[Sascha Hauer]

Arnd, Olof,

What's the status of this? I assume you haven't pulled it for -rc since
it's not important enough, but could you pull it for -next then?

Thanks
 Sascha

On Tue, Feb 05, 2013 at 10:58:44AM +0100, Sascha Hauer wrote:
> Hi Arnd, Olof,
> 
> Please pull these two fixes for v3.8
> 
> Sascha
> 
> The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7:
> 
>   Linux 3.8-rc6 (2013-02-01 12:08:14 +1100)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/imx/linux-2.6.git tags/arm-imx-clk-fixes
> 
> for you to fetch changes up to 4b526ca5f627188425184a22ed46c91baa602d43:
> 
>   ARM: i.MX25: clk: parent per5_clk to AHB clock (2013-02-05 10:54:35 +0100)
> 
> ----------------------------------------------------------------
> ARM: i.MX: clock fixes
> 
> - fix wrong timer clock on i.MX25 leading to strange timing inconsistencies
> - fix SPI clocks for i.MX27
> 
> ----------------------------------------------------------------
> Gwenhael Goavec-Merou (1):
>       ARM: imx27: clk-imx27: SPI: Rename IPG clock and add PER clock
> 
> Steffen Trumtrar (1):
>       ARM: i.MX25: clk: parent per5_clk to AHB clock
> 
>  arch/arm/mach-imx/clk-imx25.c |    3 +++
>  arch/arm/mach-imx/clk-imx27.c |    9 ++++++---
>  2 files changed, 9 insertions(+), 3 deletions(-)
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[GIT PULL] i.MX clock fixes for v3.8

[Arnd Bergmann]

On Tuesday 12 February 2013, Sascha Hauer wrote:
> Arnd, Olof,
> 
> What's the status of this? I assume you haven't pulled it for -rc since
> it's not important enough, but could you pull it for -next then?
> 

Sorry for the delay, I've pulled it into the next/fixes-non-critical branch
now.

	Arnd