mbox

[GIT,PULL] DaVinci fixes for v3.3-rc

Message ID DF0F476B391FA8409C78302C7BA518B6317A70FB@DBDE01.ent.ti.com
State New
Headers show

Pull-request

git://gitorious.org/linux-davinci/linux-davinci.git fixes

Message

Sekhar Nori Jan. 27, 2012, 5:26 p.m. UTC
Hi Olof, Arnd,

Can you please pull these DaVinci fixes for the next v3.3-rc?
Both the patches have not been stable tagged. The fix by me
is a v3.3 regression. The fix by Bas van den Berg is not critical
enough to get into stable kernels.

Thanks,
Sekhar

The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
  Linus Torvalds (1):
        Linux 3.3-rc1

are available in the git repository at:

  git://gitorious.org/linux-davinci/linux-davinci.git fixes

Bas van den Berg (1):
      ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks

Sekhar Nori (1):
      ARM: davinci: update mdio bus name

 arch/arm/mach-davinci/board-da850-evm.c     |    2 +-
 arch/arm/mach-davinci/board-dm365-evm.c     |    2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c    |    2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c    |    2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   |    2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c |    2 +-
 arch/arm/mach-davinci/board-sffsdr.c        |    2 +-
 arch/arm/mach-davinci/da850.c               |   32 ---------------------------
 8 files changed, 7 insertions(+), 39 deletions(-)

Comments

Olof Johansson Jan. 29, 2012, 10:39 p.m. UTC | #1
Hi,

On Fri, Jan 27, 2012 at 9:26 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> Hi Olof, Arnd,
>
> Can you please pull these DaVinci fixes for the next v3.3-rc?
> Both the patches have not been stable tagged. The fix by me
> is a v3.3 regression. The fix by Bas van den Berg is not critical
> enough to get into stable kernels.
>
> Thanks,
> Sekhar
>
> The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
>  Linus Torvalds (1):
>        Linux 3.3-rc1
>
> are available in the git repository at:
>
>  git://gitorious.org/linux-davinci/linux-davinci.git fixes
>
> Bas van den Berg (1):
>      ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks
>
> Sekhar Nori (1):
>      ARM: davinci: update mdio bus name

Looks like the clock removal is almost crossing over into cleanup
territory not a fix. In the future please help us out by briefly
motivate why it's a fix (for something that is broken) and not a
cleanup if it's not obvious from reading it -- noncritical fixes are
usually saved for the next merge window instead.

With that said; I've pulled the branch.


Thanks!

-Olof
Sekhar Nori Jan. 30, 2012, 5:16 p.m. UTC | #2
Hi Olof,

On Mon, Jan 30, 2012 at 04:09:37, Olof Johansson wrote:
> Hi,
> 
> On Fri, Jan 27, 2012 at 9:26 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> > Hi Olof, Arnd,
> >
> > Can you please pull these DaVinci fixes for the next v3.3-rc?
> > Both the patches have not been stable tagged. The fix by me
> > is a v3.3 regression. The fix by Bas van den Berg is not critical
> > enough to get into stable kernels.
> >
> > Thanks,
> > Sekhar
> >
> > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
> >  Linus Torvalds (1):
> >        Linux 3.3-rc1
> >
> > are available in the git repository at:
> >
> >  git://gitorious.org/linux-davinci/linux-davinci.git fixes
> >
> > Bas van den Berg (1):
> >      ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks
> >
> > Sekhar Nori (1):
> >      ARM: davinci: update mdio bus name
> 
> Looks like the clock removal is almost crossing over into cleanup
> territory not a fix. In the future please help us out by briefly
> motivate why it's a fix (for something that is broken) and not a
> cleanup if it's not obvious from reading it -- noncritical fixes are
> usually saved for the next merge window instead.

I categorized it as a fix since the path removes clocks which don't
exist in hardware. Accessing such clocks will cause undefined behavior.

The patch description does say that the clocks don't exist in hardware.
Code without the patch is definitely outside the specification.

In this regard, what could have been done better in the patch description?

Thanks,
Sekhar
Olof Johansson Jan. 31, 2012, 5:59 a.m. UTC | #3
Hi,

On Mon, Jan 30, 2012 at 9:16 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> Hi Olof,
>
> On Mon, Jan 30, 2012 at 04:09:37, Olof Johansson wrote:
>> Hi,
>>
>> On Fri, Jan 27, 2012 at 9:26 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
>> > Hi Olof, Arnd,
>> >
>> > Can you please pull these DaVinci fixes for the next v3.3-rc?
>> > Both the patches have not been stable tagged. The fix by me
>> > is a v3.3 regression. The fix by Bas van den Berg is not critical
>> > enough to get into stable kernels.
>> >
>> > Thanks,
>> > Sekhar
>> >
>> > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
>> >  Linus Torvalds (1):
>> >        Linux 3.3-rc1
>> >
>> > are available in the git repository at:
>> >
>> >  git://gitorious.org/linux-davinci/linux-davinci.git fixes
>> >
>> > Bas van den Berg (1):
>> >      ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks
>> >
>> > Sekhar Nori (1):
>> >      ARM: davinci: update mdio bus name
>>
>> Looks like the clock removal is almost crossing over into cleanup
>> territory not a fix. In the future please help us out by briefly
>> motivate why it's a fix (for something that is broken) and not a
>> cleanup if it's not obvious from reading it -- noncritical fixes are
>> usually saved for the next merge window instead.
>
> I categorized it as a fix since the path removes clocks which don't
> exist in hardware. Accessing such clocks will cause undefined behavior.
>
> The patch description does say that the clocks don't exist in hardware.
> Code without the patch is definitely outside the specification.
>
> In this regard, what could have been done better in the patch description?

A brief note as to why this should be cleaned up in time for 3.3
instead of wait for the 3.4 merge window (i.e. explain what breaks
with using the kernel if this isn't picked up).

If the definitions are wrong, and there are no in-tree users of them,
it's less critical to get an urgent fix in -- especially if the broken
code wasn't added in this merge window. Later in the -rc release cycle
this becomes more important, since technically only regressions and
critical bugfixes are supposed to go in then.

Anyway, I am splitting hairs here. The fix was good to go in, and I'm
not looking to argue over it. :)


-Olof