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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdVEj6MGtUPYLmGCtMcLxKs4rLoh+if23_Bk1p=qwQM_Gg@mail.gmail.com>
Date:	Wed, 30 Dec 2015 11:17:59 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	David Miller <davem@...emloft.net>
Cc:	Heiko Stübner <heiko@...ech.de>,
	zhengxing@...k-chips.com,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Kees Cook <keescook@...gle.com>, leozwang@...gle.comi,
	Russell King <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

Hi David,

On Wed, Dec 30, 2015 at 2:48 AM, David Miller <davem@...emloft.net> wrote:
> From: Heiko Stübner <heiko@...ech.de>
> 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.

> It looks better to put it all together as a unit, via one series, with
> a merge commit containing your "[PATCH 0/N]" description in the commit
> message.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html