From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933392AbcH2OmV (ORCPT ); Mon, 29 Aug 2016 10:42:21 -0400 Received: from mail.skyhub.de ([78.46.96.112]:56731 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757185AbcH2OmH (ORCPT ); Mon, 29 Aug 2016 10:42:07 -0400 Date: Mon, 29 Aug 2016 15:51:30 +0200 From: Borislav Petkov To: Shawn Guo Cc: York Sun , Mark Rutland , yangbo lu , Liu Gang , morbidrsa@gmail.com, linux-arm-kernel@lists.infradead.org, Arnd Bergmann , devicetree@vger.kernel.org, Bhupesh Sharma , Catalin Marinas , Will Deacon , stuart.yoder@nxp.com, linux-kernel@vger.kernel.org, oss@buserror.net, Rob Herring , Rajesh Bhagat , Olof Johansson , Mingkai Hu , Li Yang , Yuan Yao , linux-edac@vger.kernel.org Subject: Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs Message-ID: <20160829135130.GB28806@nazgul.tnic> References: <1470780000-16750-1-git-send-email-york.sun@nxp.com> <20160812091354.GB333@nazgul.tnic> <20160829063448.GA32489@tiger> <20160829080530.GA25468@nazgul.tnic> <20160829083350.GL30790@tiger> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160829083350.GL30790@tiger> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 29, 2016 at 04:33:50PM +0800, Shawn Guo wrote: > To avoid potential merge conflicts. Haven't heard of any so far. And I don't see how adding 1 or 2 DT entries more per driver is a serious merge conflict. > Unless there are hard dependencies like making it compile, avoiding > regression or maintaining bisect, patches should go through their > established subsystem/architecture tree. Well, doh, the driver simply doesn't work. How are people even supposed to test the EDAC tree? Why is it even such a big deal if it is acked by the proper maintainers? Cross-tree maintainer acking happens all the time. So don't tell me the merge conflicts are your big issue with this. > Luckily. If there are many patches on architecture DT branch changing > the same file, when driver branch and DT branch merges in upstream > branch, there will likely be merge conflicts. So? There are tools to resolve those. And again, the DT changes for EDAC are basically adding blocks so resolving those conflicts should be trivial most of the time. So no, I don't consider the potential merge conflicts an issue here. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs Date: Mon, 29 Aug 2016 15:51:30 +0200 Message-ID: <20160829135130.GB28806@nazgul.tnic> References: <1470780000-16750-1-git-send-email-york.sun@nxp.com> <20160812091354.GB333@nazgul.tnic> <20160829063448.GA32489@tiger> <20160829080530.GA25468@nazgul.tnic> <20160829083350.GL30790@tiger> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160829083350.GL30790@tiger> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Shawn Guo Cc: Mark Rutland , devicetree@vger.kernel.org, Liu Gang , morbidrsa@gmail.com, linux-edac@vger.kernel.org, Arnd Bergmann , Bhupesh Sharma , Catalin Marinas , Will Deacon , stuart.yoder@nxp.com, linux-kernel@vger.kernel.org, oss@buserror.net, Rob Herring , Rajesh Bhagat , Yuan Yao , Olof Johansson , York Sun , Li Yang , Mingkai Hu , linux-arm-kernel@lists.infradead.org, yangbo lu List-Id: devicetree@vger.kernel.org On Mon, Aug 29, 2016 at 04:33:50PM +0800, Shawn Guo wrote: > To avoid potential merge conflicts. Haven't heard of any so far. And I don't see how adding 1 or 2 DT entries more per driver is a serious merge conflict. > Unless there are hard dependencies like making it compile, avoiding > regression or maintaining bisect, patches should go through their > established subsystem/architecture tree. Well, doh, the driver simply doesn't work. How are people even supposed to test the EDAC tree? Why is it even such a big deal if it is acked by the proper maintainers? Cross-tree maintainer acking happens all the time. So don't tell me the merge conflicts are your big issue with this. > Luckily. If there are many patches on architecture DT branch changing > the same file, when driver branch and DT branch merges in upstream > branch, there will likely be merge conflicts. So? There are tools to resolve those. And again, the DT changes for EDAC are basically adding blocks so resolving those conflicts should be trivial most of the time. So no, I don't consider the potential merge conflicts an issue here. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- From mboxrd@z Thu Jan 1 00:00:00 1970 From: bp@alien8.de (Borislav Petkov) Date: Mon, 29 Aug 2016 15:51:30 +0200 Subject: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs In-Reply-To: <20160829083350.GL30790@tiger> References: <1470780000-16750-1-git-send-email-york.sun@nxp.com> <20160812091354.GB333@nazgul.tnic> <20160829063448.GA32489@tiger> <20160829080530.GA25468@nazgul.tnic> <20160829083350.GL30790@tiger> Message-ID: <20160829135130.GB28806@nazgul.tnic> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Aug 29, 2016 at 04:33:50PM +0800, Shawn Guo wrote: > To avoid potential merge conflicts. Haven't heard of any so far. And I don't see how adding 1 or 2 DT entries more per driver is a serious merge conflict. > Unless there are hard dependencies like making it compile, avoiding > regression or maintaining bisect, patches should go through their > established subsystem/architecture tree. Well, doh, the driver simply doesn't work. How are people even supposed to test the EDAC tree? Why is it even such a big deal if it is acked by the proper maintainers? Cross-tree maintainer acking happens all the time. So don't tell me the merge conflicts are your big issue with this. > Luckily. If there are many patches on architecture DT branch changing > the same file, when driver branch and DT branch merges in upstream > branch, there will likely be merge conflicts. So? There are tools to resolve those. And again, the DT changes for EDAC are basically adding blocks so resolving those conflicts should be trivial most of the time. So no, I don't consider the potential merge conflicts an issue here. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --