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
| ||
|
Date: Sun, 23 Aug 2015 16:52:32 -0700 From: Olof Johansson <olof@...om.net> To: Rob Herring <robherring2@...il.com> Cc: Ian Campbell <ian.campbell@...rix.com>, "arm@...nel.org" <arm@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>, Mark Rutland <mark.rutland@....com>, Kumar Gala <galak@...eaurora.org>, Liviu Dudau <liviu.dudau@....com>, Sudeep Holla <sudeep.holla@....com>, Lorenzo Pieralisi <lorenzo.pieralisi@....com>, Russell King <linux@....linux.org.uk>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Kristina Martsenko <kristina.martsenko@....com>, Kevin Hilman <khilman@...aro.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Linux Kbuild mailing list <linux-kbuild@...r.kernel.org> Subject: Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files. On Sun, Aug 23, 2015 at 4:42 PM, Rob Herring <robherring2@...il.com> wrote: > On Sun, Aug 23, 2015 at 6:13 PM, Olof Johansson <olof@...om.net> wrote: >> On Fri, Aug 14, 2015 at 2:21 PM, Rob Herring <robherring2@...il.com> wrote: >>> +arm-soc >>> >>> On Tue, Aug 11, 2015 at 5:07 AM, Ian Campbell <ian.campbell@...rix.com> wrote: >>>> On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote: >>>>> Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on >>>>> LogicTile Express 20MG") added a new dts file to arch/arm64 which >>>>> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a >>>>> .dtsi supplied by arch/arm. >>>>> >>>>> Unfortunately this causes some issues for the split device tree >>>>> repository[0], since things get moved around there. In that context >>>>> the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts >>>>> while the include is at src/arm/vexpress-v2m-rs1.dtsi. >>>> >>>> Hi Grant, >>>> >>>> Do you think there is any chance of getting this into 4.2-rc$NEXT or shall >>>> we wait until 4.3? I'm assuming this should go via the DT tree, but maybe >>>> it should go via an ARM tree? >>> >>> I was assuming this would go thru the arm-soc tree which is why I >>> acked it. It is getting a bit late for 4.2 at this point, but I guess >>> the standalone tree remains broken for these platforms until this is >>> done. Probably not such a big deal in grand scheme of things. >> >> I'm cc:d in the far tail of a thread, so I'll just comment here >> instead of further up: >> >> I'm not a fan at all of creating kernel/dts/<arch>/*, at least if >> there's expected to be contents in there. >> >> We don't have include/linux/asm-<arch>/ in the common tree either. >> Let's not create that for dts. > > I'd really like to move ALL dts files from arch/*. There's nothing > really tied to the architecture. They may happen to use some bindings > that only apply to an architecture, but fundamentally they don't > depend on the arch. Also, I'd like to be able to do "make all-dtbs" > and build every dtb in the tree. The main benefit of keeping it per architecture and platform is that it partitions the maintainer and review space a bit. Right now it's not possible to do even per-arch "all-dtbs" since only the currently configured platforms will get their dtbs compiled. > That said, I'm not crazy enough to propose this re-org in the kernel > tree, but would like to do that if/when we moved dts files out of the > kernel. I believe this is currently still quite firmly in the "if" stage. :( >> So, while I'm all for a prefix-based sharing of DTSI files, I don't >> want them to go in a common kernel/dts directory. >> >> Besides sharing some snippets between arm and arm64, what else is >> expected to need to go into such a shared location today? > > Overlays. You easily have the same sharing of common boards. There are > also usecases of overlays on architectures that don't generally use DT > (x86). Ok, overlays might make sense if they can be made to work generically enough and not be tied to expectations of the base board platform. Still, even then I don't see dts as a core kernel feature (kernel/*), lib/* might make more sense. And I don't want to see things like vexpress stuff in there. > We could also see sharing between PPC and ARM on FSL networking parts, > but I've not heard if they actually have that problem. Yeah, there could potentially be some sharing between MIPS and ARM{,64} too, but I don't know if we'll actually see it done. -Olof -- 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/
Powered by blists - more mailing lists