All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] at91 first cleanup series for 3.4
Date: Mon, 27 Feb 2012 17:31:02 +0000	[thread overview]
Message-ID: <201202271731.03230.arnd@arndb.de> (raw)
In-Reply-To: <4F4674F2.8090603@atmel.com>

On Thursday 23 February 2012, Nicolas Ferre wrote:
> This series removes the at91_sys_read/write() functions that where
> used for all System Controller devices. The static offsets that were
> used prevented us from compiling several AT91 SoC support in a single
> zImage.
> 
> The other cleanup is the move of some early console initialization. In
> addition, some Makefile.boot modifications have been performed to be
> able to make .dtb files.
> 
> All this goes on top of current material that is already in arm-soc
> git tree (merge of all at91/* branches. You can find it in the same git
> tree with at91-3.4-base2 branch name).
> 
> 
> The following changes since commit 11a25ea7e4f870a37093258f577e11cec703e37e:
> 
>   Merge remote-tracking branch 'armsoc/at91/9x5' into at91-3.4-base2 (2012-02-11 14:33:03 +0100)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup

Hi Nicolas,

I cannot merge this into the next/cleanup branch because you have based it
on top of a non-cleanup branch. There are three ways out of this:

1. rebase the entire branch on a changeset that only contains upstream and
cleanup branches, and let me deal with merge conflicts against the at91/9x5
branch.

2. Split this series into two parts, with the simple cleanups going directly
in as in 1, but cleanups on top of the at91/9x5 branch get applied to that
branch only.

3. Create a new next/cleanup2 branch with this pull request that I submit
to Linus separately from the other cleanups.

Which one should it be?

I'm also still not entirely happy with the contents because the newly
introduced macros all still use __raw_readl() instead of readl_relaxed(),
and because the rtt setup appears unnecessarily complex while at the same
time still not sufficient for a combined at91 kernel. It would be nice
if those could be fixed, but I would still take the series without changing
the rtt code because we have not really come to a conclusion otherwise
and the series generally moves things into the right direction.

I've applied your series to the staging/cleanup branch for now, which
means it gets into linux-next but I won't send to Linus unless I get
an update.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Olof Johansson <olof@lixom.net>,
	"Jean-Christophe PLAGNIOL-VILLARD" <plagnioj@jcrosoft.com>,
	"linux-arm-kernel" <linux-arm-kernel@lists.infradead.org>,
	Rob Herring <robherring2@gmail.com>,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	Ryan Mallon <ryan@bluewatersys.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] at91 first cleanup series for 3.4
Date: Mon, 27 Feb 2012 17:31:02 +0000	[thread overview]
Message-ID: <201202271731.03230.arnd@arndb.de> (raw)
In-Reply-To: <4F4674F2.8090603@atmel.com>

On Thursday 23 February 2012, Nicolas Ferre wrote:
> This series removes the at91_sys_read/write() functions that where
> used for all System Controller devices. The static offsets that were
> used prevented us from compiling several AT91 SoC support in a single
> zImage.
> 
> The other cleanup is the move of some early console initialization. In
> addition, some Makefile.boot modifications have been performed to be
> able to make .dtb files.
> 
> All this goes on top of current material that is already in arm-soc
> git tree (merge of all at91/* branches. You can find it in the same git
> tree with at91-3.4-base2 branch name).
> 
> 
> The following changes since commit 11a25ea7e4f870a37093258f577e11cec703e37e:
> 
>   Merge remote-tracking branch 'armsoc/at91/9x5' into at91-3.4-base2 (2012-02-11 14:33:03 +0100)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/at91linux/linux-at91.git at91-3.4-base2+cleanup

Hi Nicolas,

I cannot merge this into the next/cleanup branch because you have based it
on top of a non-cleanup branch. There are three ways out of this:

1. rebase the entire branch on a changeset that only contains upstream and
cleanup branches, and let me deal with merge conflicts against the at91/9x5
branch.

2. Split this series into two parts, with the simple cleanups going directly
in as in 1, but cleanups on top of the at91/9x5 branch get applied to that
branch only.

3. Create a new next/cleanup2 branch with this pull request that I submit
to Linus separately from the other cleanups.

Which one should it be?

I'm also still not entirely happy with the contents because the newly
introduced macros all still use __raw_readl() instead of readl_relaxed(),
and because the rtt setup appears unnecessarily complex while at the same
time still not sufficient for a combined at91 kernel. It would be nice
if those could be fixed, but I would still take the series without changing
the rtt code because we have not really come to a conclusion otherwise
and the series generally moves things into the right direction.

I've applied your series to the staging/cleanup branch for now, which
means it gets into linux-next but I won't send to Linus unless I get
an update.

	Arnd

  reply	other threads:[~2012-02-27 17:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 17:18 [GIT PULL] at91 first cleanup series for 3.4 Nicolas Ferre
2012-02-23 17:18 ` Nicolas Ferre
2012-02-27 17:31 ` Arnd Bergmann [this message]
2012-02-27 17:31   ` Arnd Bergmann
2012-02-28 11:19   ` Nicolas Ferre
2012-02-28 11:19     ` Nicolas Ferre
2012-02-28 12:18     ` Arnd Bergmann
2012-02-28 12:18       ` Arnd Bergmann
2012-02-29  9:40       ` Nicolas Ferre
2012-02-29  9:40         ` Nicolas Ferre
2012-02-29 12:15         ` Arnd Bergmann
2012-02-29 12:15           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201202271731.03230.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.