[GIT PULL] [3.2] Please pull tegra boards for 3.2

[GIT PULL] [3.2] Please pull tegra boards for 3.2

[Olof Johansson]

Hi Arnd,

Please pull the first set of tegra/board patches for 3.2:


The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9:

  Merge branch 'slab/urgent' of
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
(2011-08-09 08:42:16 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2

Marc Dietrich (5):
      ARM: tegra: paz00: add support serial port on JP1
      ARM: tegra: paz00: enable rfkill for internal wifi card
      ARM: tegra: paz00: enable wifi led
      ARM: tegra: paz00: reorder the SDHCI channel init
      ARM: tegra: paz00: add clocks required for usb operation

Stephen Warren (4):
      ARM: Tegra: Harmony: Add USB device
      ARM: Tegra: Seaboard board updates for audio
      ARM: Tegra: Seaboard: Add USB devices
      ARM: Tegra: Force PORT_TEGRA as the UART type

 arch/arm/mach-tegra/board-harmony.c         |    5 +-
 arch/arm/mach-tegra/board-paz00-pinmux.c    |    3 +
 arch/arm/mach-tegra/board-paz00.c           |   62 ++++++++++++++++++++-
 arch/arm/mach-tegra/board-paz00.h           |   16 ++++-
 arch/arm/mach-tegra/board-seaboard-pinmux.c |    6 +-
 arch/arm/mach-tegra/board-seaboard.c        |   81 ++++++++++++++++++++++++++-
 arch/arm/mach-tegra/board-seaboard.h        |   12 +++-
 arch/arm/mach-tegra/board-trimslice.c       |    3 +-
 8 files changed, 173 insertions(+), 15 deletions(-)

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Arnd Bergmann]

On Sunday 14 August 2011, Olof Johansson wrote:
> 
> Hi Arnd,
> 
> Please pull the first set of tegra/board patches for 3.2:
> 
> 
> The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9:
> 
>  Merge branch 'slab/urgent' of
> git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
> (2011-08-09 08:42:16 -0700)
> 
> are available in the git repository at:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2
> 

Hi Olof,

The contents all look good, but I'm undecided whether we should have
branches that are not based on a -rc release. In your case, it's
halfway between -rc1 and -rc2.

Do others have an opinion? If we decide to take development branches
only when they are based on a proper -rc, I'll do the simple rebase
of the patches and push them out, otherwise I'll push them as they are.

	Arnd

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Nicolas Pitre]

On Tue, 16 Aug 2011, Arnd Bergmann wrote:

> On Sunday 14 August 2011, Olof Johansson wrote:
> > 
> > Hi Arnd,
> > 
> > Please pull the first set of tegra/board patches for 3.2:
> > 
> > 
> > The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9:
> > 
> >  Merge branch 'slab/urgent' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
> > (2011-08-09 08:42:16 -0700)
> > 
> > are available in the git repository at:
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2
> > 
> 
> Hi Olof,
> 
> The contents all look good, but I'm undecided whether we should have
> branches that are not based on a -rc release. In your case, it's
> halfway between -rc1 and -rc2.
> 
> Do others have an opinion? If we decide to take development branches
> only when they are based on a proper -rc, I'll do the simple rebase
> of the patches and push them out, otherwise I'll push them as they are.

Although this might be a nicety, I personally don't particularly care 
about the base being set on a tag. I think that keeping the original 
committer info intact is more valuable.


Nicolas

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Thomas Gleixner]

On Tue, 16 Aug 2011, Nicolas Pitre wrote:

> On Tue, 16 Aug 2011, Arnd Bergmann wrote:
> 
> > On Sunday 14 August 2011, Olof Johansson wrote:
> > > 
> > > Hi Arnd,
> > > 
> > > Please pull the first set of tegra/board patches for 3.2:
> > > 
> > > 
> > > The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9:
> > > 
> > >  Merge branch 'slab/urgent' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
> > > (2011-08-09 08:42:16 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >  git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2
> > > 
> > 
> > Hi Olof,
> > 
> > The contents all look good, but I'm undecided whether we should have
> > branches that are not based on a -rc release. In your case, it's
> > halfway between -rc1 and -rc2.
> > 
> > Do others have an opinion? If we decide to take development branches
> > only when they are based on a proper -rc, I'll do the simple rebase
> > of the patches and push them out, otherwise I'll push them as they are.
> 
> Although this might be a nicety, I personally don't particularly care 
> about the base being set on a tag. I think that keeping the original 
> committer info intact is more valuable.

Right. In general having a devel branch based on a tag is a good
thing, but as long as it's not some random commit from the middle of
the merge window, it's fine.

Thanks,

	tglx

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Olof Johansson]

On Tue, Aug 16, 2011 at 7:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 14 August 2011, Olof Johansson wrote:
>>
>> Hi Arnd,
>>
>> Please pull the first set of tegra/board patches for 3.2:
>>
>>
>> The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9:
>>
>> ?Merge branch 'slab/urgent' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
>> (2011-08-09 08:42:16 -0700)
>>
>> are available in the git repository at:
>>
>> ?git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2
>>
>
> Hi Olof,
>
> The contents all look good, but I'm undecided whether we should have
> branches that are not based on a -rc release. In your case, it's
> halfway between -rc1 and -rc2.
>
> Do others have an opinion? If we decide to take development branches
> only when they are based on a proper -rc, I'll do the simple rebase
> of the patches and push them out, otherwise I'll push them as they are.

I guess it depends on what you and others prefer -- if you want to
aggregate the branches in arm-soc.git through the development weeks,
or if you prefer to get most of the merge requests when platform
maintainers are getting ready for the merge window and feeding things
up?

Either is fine with me -- if it's easier for me to hold off the merge
requests a while, then I'll start a for-next branch and ask Stephen to
add it, and rebase it a few times up until when the merge request to
arm-soc is sent. Maybe it's just easier for everyone to do it that way
-- the drawback is that there's less visibility about what's about to
go in until the merge requests start to drop in late in the cycle. The
git history won't be quite as wide then either.


-Olof

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Arnd Bergmann]

On Tuesday 16 August 2011 12:30:50 Olof Johansson wrote:
> On Tue, Aug 16, 2011 at 7:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > The contents all look good, but I'm undecided whether we should have
> > branches that are not based on a -rc release. In your case, it's
> > halfway between -rc1 and -rc2.
> >
> > Do others have an opinion? If we decide to take development branches
> > only when they are based on a proper -rc, I'll do the simple rebase
> > of the patches and push them out, otherwise I'll push them as they are.
> 
> I guess it depends on what you and others prefer -- if you want to
> aggregate the branches in arm-soc.git through the development weeks,
> or if you prefer to get most of the merge requests when platform
> maintainers are getting ready for the merge window and feeding things
> up?

I definitely want to have the patches as early as possible, but not
more than one pull request per branch per week or -rc ideally.

> Either is fine with me -- if it's easier for me to hold off the merge
> requests a while, then I'll start a for-next branch and ask Stephen to
> add it, and rebase it a few times up until when the merge request to
> arm-soc is sent. Maybe it's just easier for everyone to do it that way
> -- the drawback is that there's less visibility about what's about to
> go in until the merge requests start to drop in late in the cycle. The
> git history won't be quite as wide then either.

I would prefer to have all branches that I send to Linus go into the
-next through the arm-soc tree as well, not get sent there individually.

Basically, when you consider patches stable and ready for upstream
and expect no further changes, I'll pull the patches into arm-soc.git
and you can add further patches on top of the branch that I have already
pulled (not on an aggregated branch) and I can pull that again. If you
have unrelated changes, then I'd prefer them to be on top of an -rc
release for the next pull request.

	Arnd

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Olof Johansson]

On Tue, Aug 16, 2011 at 2:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 16 August 2011 12:30:50 Olof Johansson wrote:
>> On Tue, Aug 16, 2011 at 7:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >
>> > The contents all look good, but I'm undecided whether we should have
>> > branches that are not based on a -rc release. In your case, it's
>> > halfway between -rc1 and -rc2.
>> >
>> > Do others have an opinion? If we decide to take development branches
>> > only when they are based on a proper -rc, I'll do the simple rebase
>> > of the patches and push them out, otherwise I'll push them as they are.
>>
>> I guess it depends on what you and others prefer -- if you want to
>> aggregate the branches in arm-soc.git through the development weeks,
>> or if you prefer to get most of the merge requests when platform
>> maintainers are getting ready for the merge window and feeding things
>> up?
>
> I definitely want to have the patches as early as possible, but not
> more than one pull request per branch per week or -rc ideally.

That sounds reasonable.

> I would prefer to have all branches that I send to Linus go into the
> -next through the arm-soc tree as well, not get sent there individually.
>
> Basically, when you consider patches stable and ready for upstream
> and expect no further changes, I'll pull the patches into arm-soc.git
> and you can add further patches on top of the branch that I have already
> pulled (not on an aggregated branch) and I can pull that again. If you
> have unrelated changes, then I'd prefer them to be on top of an -rc
> release for the next pull request.

Ok. Sounds like there might be some use for a temporary "work in
progress" branch for linux-next for patches that are nearly ready to
go but not quite that needs air time, but not really for anything
beyond that.

None of the ones in this case apply to this scenario so I'll resend a
fresh pull request based on -rc3 as soon as the branch rebase has
propagated out from master.kernel.org.


-Olof

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Russell King - ARM Linux]

On Thu, Aug 25, 2011 at 10:23:21PM -0700, Olof Johansson wrote:
> Ok. Sounds like there might be some use for a temporary "work in
> progress" branch for linux-next for patches that are nearly ready to
> go but not quite that needs air time, but not really for anything
> beyond that.

Bad idea.

linux-next's policy is that everything in linux-next should be ready
for mainline - not nearly ready.

Linus is threatening at the next merge window to ignore pull requests
from maintainers, and just pull the entire linux-next tree into his at
the beginning.  Anything in linux-next which is "work in progress" will
therefore find its way immediately into mainline in whatever state it's
in.

So, everyone needs to ensure that linux-next only contains code that's
100% ready for merging during the next merge window.  Everything else
should not be in linux-next.

Fwd: [GIT PULL] [3.2] Please pull tegra boards for 3.2

[Sascha Hauer]

On Fri, Aug 26, 2011 at 09:32:52AM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 25, 2011 at 10:23:21PM -0700, Olof Johansson wrote:
> > Ok. Sounds like there might be some use for a temporary "work in
> > progress" branch for linux-next for patches that are nearly ready to
> > go but not quite that needs air time, but not really for anything
> > beyond that.
> 
> Bad idea.
> 
> linux-next's policy is that everything in linux-next should be ready
> for mainline - not nearly ready.
> 
> Linus is threatening at the next merge window to ignore pull requests
> from maintainers, and just pull the entire linux-next tree into his at
> the beginning.  Anything in linux-next which is "work in progress" will
> therefore find its way immediately into mainline in whatever state it's
> in.

Are you referring to:

> In fact, I'm seriously considering a rather draconian measure for next
> merge window: I'll fetch the -next tree when I open the merge window,
> and if I get anything but trivial fixes that don't show up in that "next
> tree at the point of merge window open", I'll just ignore that pull
> request. Because clearly people are just not being careful enough.

I understood that he wants to check if the contents of a pull request
are already in -next and otherwise just refuses to pull. SO nothing
changes, except that you have to make sure your patches are in -next
before the merge window opens.

There may be something else on the lists I missed...

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] [3.2] Please pull tegra boards for 3.2

[Olof Johansson]

Hi Arnd,

Please pull the first set of tegra/board patches for 3.2. Same
contents as last time, but rebased on top of 3.1-rc3:

The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:

  Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2

Marc Dietrich (5):
      ARM: tegra: paz00: add support serial port on JP1
      ARM: tegra: paz00: enable rfkill for internal wifi card
      ARM: tegra: paz00: enable wifi led
      ARM: tegra: paz00: reorder the SDHCI channel init
      ARM: tegra: paz00: add clocks required for usb operation

Stephen Warren (4):
      ARM: Tegra: Harmony: Add USB device
      ARM: Tegra: Seaboard board updates for audio
      ARM: Tegra: Seaboard: Add USB devices
      ARM: Tegra: Force PORT_TEGRA as the UART type

 arch/arm/mach-tegra/board-harmony.c         |    5 +-
 arch/arm/mach-tegra/board-paz00-pinmux.c    |    3 +
 arch/arm/mach-tegra/board-paz00.c           |   62 ++++++++++++++++++++-
 arch/arm/mach-tegra/board-paz00.h           |   16 ++++-
 arch/arm/mach-tegra/board-seaboard-pinmux.c |    6 +-
 arch/arm/mach-tegra/board-seaboard.c        |   81 ++++++++++++++++++++++++++-
 arch/arm/mach-tegra/board-seaboard.h        |   12 +++-
 arch/arm/mach-tegra/board-trimslice.c       |    3 +-
 8 files changed, 173 insertions(+), 15 deletions(-)

[GIT PULL] [3.2] Please pull tegra boards for 3.2

[Arnd Bergmann]

On Friday 26 August 2011, Olof Johansson wrote:
> Please pull the first set of tegra/board patches for 3.2. Same
> contents as last time, but rebased on top of 3.1-rc3:
> 
> The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
> 
>   Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2
> 
Pulled, thanks!

	Arnd