On Sun, May 4, 2014 at 10:42 AM, Jason Cooper [off-list ref] wrote:

On Sat, May 03, 2014 at 03:51:11PM -0700, Olof Johansson wrote:

quoted

On Wed, Apr 30, 2014 at 4:45 AM, Jason Cooper [off-list ref] wrote:

quoted

On Tue, Apr 29, 2014 at 12:06:03PM -0700, Brian Norris wrote:

quoted

Hi Stephen,

On Fri, Apr 25, 2014 at 10:39:37AM -0600, Stephen Warren wrote:

quoted

On 04/17/2014 01:21 AM, Brian Norris wrote:

quoted

These defconfigs contain the CONFIG_M25P80 symbol, which is now
dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
relevant defconfigs.

At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.

I hadn't realized that the problem this patch solves was already present
in the code, so this patch is simply catching up the defconfigs rather
than part of a series which changed the code to cause the problem.

Yes, this is "catching up the defconfigs." The SPI_NOR framework is new,
and I didn't want to generate defconfig noise until a few things
stabilized (particularly, its Kconfig symbol name).

quoted

So, this needs to be applied ASAP.

I think this should be split it up so that each defconfig can go through
the tree that owns it to avoid conflicts. If you repost split up, I can
apply the tegra_defconfig change to the Tegra tree.

OK, I'll try to split it up. Is ARM unique in tracking defconfigs in
separate trees? I assume MIPS, PowerPC, and Blackfin won't require the
same splitting? I'd like to avoid 31 patches when <20 could suffice.

wrt arm-soc, typically they take all changes to multi_v7_defconfig
directly since it is prone to conflicts.  All the other ones are managed
by the individual sub-arch maintainers.

quoted

I'll also rebase on linux-next. I think there may be a few conflicts.

I can't speak for the other sub-archs, but I typically prefer that
patches be based on an -rc tag, -rc1 if possible.

This is making a trivial patch a pain to get merged.

Sorry.

No worries.

quoted

Cases like these are easiest that we just take the patch directly in
an early-merge branch (i.e. cleanup or fixes-non-critical, or a
generic depends branch), and if there's conflicts as topics are merged
in from subplatforms we can deal with it then.

Are you referring to basing on -rc1, or the series being split up to
the individual sub-arch maintainers?

*slightly* confused,

I'm referring to us taking the patch into something like our cleanup
branch, and any branches that come in from you or other subplatforms
will be merged on top, so we can resolve conflicts there and then.
We'll merge in the cleanup branch into other next/* branches as needed
to resolve the conflicts in our tree instead of percolating them all
the way up.



-Olof