[PATCH RESEND] mmc: dove: fix missing MACH_DOVE dependency

[Olof Johansson]

On Fri, May 23, 2014 at 6:41 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Fri, May 23, 2014 at 09:40:55AM +0200, Ulf Hansson wrote:
>> On 23 May 2014 09:16, Olof Johansson <olof at lixom.net> wrote:
>> > On Thu, May 22, 2014 at 2:09 AM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>> >> On 19 May 2014 20:02, Sebastian Hesselbarth
>> >> <sebastian.hesselbarth at gmail.com> wrote:
>> >>> DT-enabled Dove moved over from ARCH_DOVE in mach-dove to MACH_DOVE in
>> >>> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
>> >>> DT-only MACH_DOVE Kconfig. This slipped through the cracks and now is
>> >>> a fix to allow to build Dove's SDHCI driver for mach-mvebu on v3.15-rc.
>> >>>
>> >>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>> >>> Acked-by: Jason Cooper <jason at lakedaemon.net>
>> >>
>> >> Thanks! Picked up for the PR I send to Chris.
>> >
>> > Ulf, you might consider adding your tree to linux-next if this is
>> > going to be a common work flow for you guys.
>>
>> That's done already. :-) There are patches which makes this visible in
>> the MAINTAINERS as well, queued for 3.16.
>>
>> git://git.linaro.org/people/ulf.hansson/mmc.git next
>>
>> Though due to merge conflicts, during this release cycle, I didn't
>> want to queue any patches besides for the mmci host driver.
>>
>> >
>> > It's partially up to Chris though, if he's OK with patches going into
>> > your branch more or less being guaranteed to make it into his as well.
>> >
>>
>> Yes, we need to figure out a good work flow when using two separate
>> trees. Thanks for bringing this up!
>
> If you have any questions, please ask.  mvebu has been doing this for
> several release cycles now, and I'm also doing it for irqchip now.
>
> The biggest rule is that once you sign a tag and send a pull-request for
> it, the branch is immutable up to and including that tag.

...unless you get asked to respin based on review from the person
you're sending the request to.

This is the main problem with multi-level maintainer trees: It's hard
to run a stable non-rebasing tree as a downstream tree since there's
no actual guarantee that it'll go in as-is.


-Olof