linux-kernel - 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: <CAL_JsqKP0QsbeP-8c5XusTcFEsgNgu==ca+5Z57Wq6Yq9EHVzA@mail.gmail.com>
Date:	Wed, 30 Dec 2015 09:03:11 -0600
From:	Rob Herring <robh+dt@...nel.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	David Miller <davem@...emloft.net>,
	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>,
	"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

On Wed, Dec 30, 2015 at 4:17 AM, Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
> 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.

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/