Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

On Wed, Dec 30, 2015 at 4:17 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi David,
>
> On Wed, Dec 30, 2015 at 2:48 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>> From: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
>> Date: Tue, 29 Dec 2015 23:27:55 +0100
>>> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>>>> You have to submit this series properly, the same problem happend twice
>>>> now.
>>>>
>>>> When you submit a series you should:
>>>>
>>>> 1) Make it clear which tree you expect these changes to be applied
>>>>    to.  Here it is completely ambiguous, do you want it to go into
>>>>    my networking tree or some other subsystem tree?
>>>>
>>>> 2) You MUST keep all parties informed about all patches for a series
>>>>    like this.  That means you cannot drop netdev from patch #4 as
>>>>    you did both times.  Doing this aggravates the situation for
>>>>    #1 even more, because if a patch is not CC:'d to netdev it does
>>>>    not enter patchwork.  And if it doesn't go into patchwork, I'm
>>>>    not looking at it.
>>>
>>> I guess that is some unfortunate result of git send-email combined with
>>> get_maintainer.pl . In general I also prefer to see the whole series, but have
>>> gotten such partial series from other maintainers as well in the past, so it
>>> seems to be depending on preferences somewhat.
>>>
>>> For the series at hand, the 4th patch is the devicetree addition, which the
>>> expected way is me picking it up, after you are comfortable with the code-
>>> related changes.
>>
>> Why would it not be appropriate for a DT file change to go into my tree
>> if it corresponds to functionality created by the rest of the patches
>> in the series?
>
> Because the DT change is very likely to conflict with other DT changes.
> That's why typically all DT changes go in through the platform/architecture
> maintainer.

I assume you mean DTS changes only here. Send the DTS changes as a
separate series/patch as there is not inter-dependency (if there is,
there is a problem with the change) with DTS changes. I expect the
sub-arch maintainers to be the main reviewers of DTS files anyway. If
there is a binding doc change, then I'd prefer that to be merged with
the driver.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html