On Sat, Sep 5, 2015 at 3:11 AM, Sharma Bhupesh <bhupesh.sharma@xxxxxxxxxxxxx> wrote: >> From: pku.leo@xxxxxxxxx [mailto:pku.leo@xxxxxxxxx] >> Sent: Saturday, September 05, 2015 2:43 AM >> On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh >> <bhupesh.sharma@xxxxxxxxxxxxx> wrote: >> >> From: pku.leo@xxxxxxxxx [mailto:pku.leo@xxxxxxxxx] >> >> Sent: Friday, September 04, 2015 10:27 PM On Fri, Sep 4, 2015 at 1:57 >> >> AM, Bhupesh Sharma <bhupesh.sharma@xxxxxxxxxxxxx> wrote: >> >> > This patch adds bindings for QIXIS FPGA controller found on FSL >> boards. >> >> >> >> A general comment: when you are updating the device tree bindings. >> >> You should cc the devicetree@xxxxxxxxxxxxxxx mailing list. >> >> >> >> > >> >> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board >> >> > FPGA/CPLD connected to the IFC controller. The bindings specified >> >> > in this patch cater to those on-board FPGA/CPLD controllers. >> >> >> >> We already have the binding defined in >> >> Documentation/devicetree/bindings/powerpc/fsl/board.txt. We probably >> >> should just move it to a more generic location. >> > >> > Consolidation of powerpc and ARM bindings is something that needs to >> > be targeted by a separate patch-series, perhaps in future. >> > >> > There are a number of duplications that can be looked into, but I >> > don't think this patchset should depend on that. >> >> There might be some duplication, but we shouldn't be adding more. :) I >> would rather you directly updating that file than creating a new file >> even though the original one was in a wrong directory. >> > > IMO a PowerPC binding update makes no sense in a ARM machine patchset sent > on a arm specific mailing list. So the best approach is to merge the change with the original binding and put it into a common place. Although there were a lot of non-arch specific bindings placed into the arch folder, we should stop adding more now. Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html