From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Subject: Re: ACPI vs DT at runtime Date: Tue, 19 Nov 2013 17:19:39 +0100 [thread overview] Message-ID: <201311191719.39788.arnd@arndb.de> (raw) In-Reply-To: <20131119152157.GO5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> On Tuesday 19 November 2013, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > > > As mentioned above, I think that the work to do this is going to end up > > > as a weird ARM-specific legacy feature. We will get something wrong here > > > in a way that we have to support long-term. I would rather support > > > solely DT or solely ACPI at runtime (with a kernel supporting both), > > > rather than a mixture of both forever due to an artifact of the > > > development process. > > > > I think that depends on how whether you expect ACPI to succeed in the market > > or not. If it ends up being a historic sidenote, that's what the code > > should be. > > A precedent for this would be mach-shark, which we just removed. It > > was one of the original StrongARM machines and actually came with Open > > Firmware and a DT that was (rightfully so) converted to ATAGS format > > on boot. > > From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the > converter only converted /memory, /chosen/bootargs, and /banner-name. > That's far less complex than converting an arbitrary ACPI table, and far > less likely to hold subtle quirks that vendors will begin relying on in > their firmware. It also looks like it could have been factored out were > there more OpenFirmware systems. Right. Of course at the time, things were much simpler in general. > I think that with ACPI systems the data we would have to convert is > going to be larger and more varied than that. Given we already have code > in the kernel for handling ACPI, I believe it would be more valuable to > leverage that and support ACPI directly in those places which require it We have code in the kernel to handle power management and a couple of very specific platform devices on ACPI based x86 and Itanium PCs. We would use very little of that on ARM, and it doesn't do much of what we need at the moment. We definitely shouldn't add all that infrastructure to make it work on ARM just because someone accidentally put four letters into a requirements document and didn't understand the consequences... > > > > Also, we can either have some of our better people sort out the ACPI-to-DT > > > > translation and management, and get it done right, or we can rely on all the > > > > vendors to get ACPI right in all their drivers. While some of them will, > > > > I suspect we'll be more successful driving this from a common place. It > > > > also gives us a place to stick all the fixups for broken firmware, > > > > since the first generations of ARM servers are bound to have them. > > > > > > This common place is going to end up handling arbitrarily different > > > idioms in each format (e.g. how GPIOs are represented), and is almost > > > certainly going to become a sprawling mess. Also having "all the fixups" > > > in there makes this sound like an every-single-board file, which is > > > something I think everyone would like to avoid. > > > > I guess if it grows too big, it could be moved into a separate boot loader > > project and out of the kernel, as we do for the ATAGS-to-DT conversion > > with the impedence-matcher. > > I think there's a big difference between the impedence matcher and the > proposed ACPI => DT converter. The impedence matcher maps a well-defined > unique ID to a binary blob it knows nothing about. The proposed ACPI => > DT converter necessarily needs to map differing idioms used to represent > classes of device, and thus picks up all the domain-specific knowledge > that would otherwise be part of a particular subsystem (e.g. GPIO), or > even drivers depending on the granularity of conversion. > > To me it seems that placing this in an external blob is fundamentally > the wrong way to go. It must necessarily lump together various > unconnected concerns, and will end up mirroring the structure of Linux > subsystems and drivers. I think by the time it "grows too big", we've > already lost, having wasted our time putting something together that > should have been handled in Linux from the start. As I said, it really depends on what people actually want to do with ACPI, and why they want it. I can see some scenarios in which it would be fairly easy to do the conversion, such as when all the devices are fixed in the SoC and you just need to map a couple of GPIO lines or I2C devices. Doing the full conversion of an SoC structure otoh would be pretty crazy. > > > > Vendors can standardise of UEFI if they want, but I would much rather > > > > see them bundle DTB images with their firmware today, than rely on early > > > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > > > have to live with forever. > > > > > > I agree that today a DTB is preferable to an ACPI implementation. > > > > > > I think that mapping from ACPI => DT is less sane than building support > > > for ACPI, and is not going to help us in the long term. > > > > > > I think that we need to be involved in ACPI from today if we have any > > > hope of having something sane in future. > > > > I mostly agree, but I think that the decision whether to ignore, translate > > or implement support for ACPI BIOS implementations depends a lot on > > what kinds of systems we are going to see and the level of sophistication > > they put into their firmware. > > > > If we are basically talking about PCs with their x86 CPU removed and > > an ARM chip put in there, I think an ACPI implementation would be > > harmless enough. However if we are talking about complex SoCs that just > > have the same information in ACPI that we have in DT in a different > > format, we really need to tell the responsible developers that ACPI > > support for these just won't get merged. > > I mostly agree. However, I'm not so sure on the latter case. If ACPI > matures support for richer description (as some x86 people are pushing > for) and it's used in a sane manner, then I don't think we should > prevent that, especially if the maintenance burden is shared by the > larger Linux community. True, I just think that's too many "if"s to build a product roadmap on. It can turn into that in a couple of years, but anyone building a complex SoC today is better off assuming it won't come to that IMHO. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: ACPI vs DT at runtime Date: Tue, 19 Nov 2013 17:19:39 +0100 [thread overview] Message-ID: <201311191719.39788.arnd@arndb.de> (raw) In-Reply-To: <20131119152157.GO5914@e106331-lin.cambridge.arm.com> On Tuesday 19 November 2013, Mark Rutland wrote: > On Tue, Nov 19, 2013 at 02:05:33PM +0000, Arnd Bergmann wrote: > > > As mentioned above, I think that the work to do this is going to end up > > > as a weird ARM-specific legacy feature. We will get something wrong here > > > in a way that we have to support long-term. I would rather support > > > solely DT or solely ACPI at runtime (with a kernel supporting both), > > > rather than a mixture of both forever due to an artifact of the > > > development process. > > > > I think that depends on how whether you expect ACPI to succeed in the market > > or not. If it ends up being a historic sidenote, that's what the code > > should be. > > A precedent for this would be mach-shark, which we just removed. It > > was one of the original StrongARM machines and actually came with Open > > Firmware and a DT that was (rightfully so) converted to ATAGS format > > on boot. > > From the looks of the removed arch/arm/boot/compressed/ofw-shark.c, the > converter only converted /memory, /chosen/bootargs, and /banner-name. > That's far less complex than converting an arbitrary ACPI table, and far > less likely to hold subtle quirks that vendors will begin relying on in > their firmware. It also looks like it could have been factored out were > there more OpenFirmware systems. Right. Of course at the time, things were much simpler in general. > I think that with ACPI systems the data we would have to convert is > going to be larger and more varied than that. Given we already have code > in the kernel for handling ACPI, I believe it would be more valuable to > leverage that and support ACPI directly in those places which require it We have code in the kernel to handle power management and a couple of very specific platform devices on ACPI based x86 and Itanium PCs. We would use very little of that on ARM, and it doesn't do much of what we need at the moment. We definitely shouldn't add all that infrastructure to make it work on ARM just because someone accidentally put four letters into a requirements document and didn't understand the consequences... > > > > Also, we can either have some of our better people sort out the ACPI-to-DT > > > > translation and management, and get it done right, or we can rely on all the > > > > vendors to get ACPI right in all their drivers. While some of them will, > > > > I suspect we'll be more successful driving this from a common place. It > > > > also gives us a place to stick all the fixups for broken firmware, > > > > since the first generations of ARM servers are bound to have them. > > > > > > This common place is going to end up handling arbitrarily different > > > idioms in each format (e.g. how GPIOs are represented), and is almost > > > certainly going to become a sprawling mess. Also having "all the fixups" > > > in there makes this sound like an every-single-board file, which is > > > something I think everyone would like to avoid. > > > > I guess if it grows too big, it could be moved into a separate boot loader > > project and out of the kernel, as we do for the ATAGS-to-DT conversion > > with the impedence-matcher. > > I think there's a big difference between the impedence matcher and the > proposed ACPI => DT converter. The impedence matcher maps a well-defined > unique ID to a binary blob it knows nothing about. The proposed ACPI => > DT converter necessarily needs to map differing idioms used to represent > classes of device, and thus picks up all the domain-specific knowledge > that would otherwise be part of a particular subsystem (e.g. GPIO), or > even drivers depending on the granularity of conversion. > > To me it seems that placing this in an external blob is fundamentally > the wrong way to go. It must necessarily lump together various > unconnected concerns, and will end up mirroring the structure of Linux > subsystems and drivers. I think by the time it "grows too big", we've > already lost, having wasted our time putting something together that > should have been handled in Linux from the start. As I said, it really depends on what people actually want to do with ACPI, and why they want it. I can see some scenarios in which it would be fairly easy to do the conversion, such as when all the devices are fixed in the SoC and you just need to map a couple of GPIO lines or I2C devices. Doing the full conversion of an SoC structure otoh would be pretty crazy. > > > > Vendors can standardise of UEFI if they want, but I would much rather > > > > see them bundle DTB images with their firmware today, than rely on early > > > > buggy and still-early-on-the-learning-curve ACPI bindings that we then > > > > have to live with forever. > > > > > > I agree that today a DTB is preferable to an ACPI implementation. > > > > > > I think that mapping from ACPI => DT is less sane than building support > > > for ACPI, and is not going to help us in the long term. > > > > > > I think that we need to be involved in ACPI from today if we have any > > > hope of having something sane in future. > > > > I mostly agree, but I think that the decision whether to ignore, translate > > or implement support for ACPI BIOS implementations depends a lot on > > what kinds of systems we are going to see and the level of sophistication > > they put into their firmware. > > > > If we are basically talking about PCs with their x86 CPU removed and > > an ARM chip put in there, I think an ACPI implementation would be > > harmless enough. However if we are talking about complex SoCs that just > > have the same information in ACPI that we have in DT in a different > > format, we really need to tell the responsible developers that ACPI > > support for these just won't get merged. > > I mostly agree. However, I'm not so sure on the latter case. If ACPI > matures support for richer description (as some x86 people are pushing > for) and it's used in a sane manner, then I don't think we should > prevent that, especially if the maintenance burden is shared by the > larger Linux community. True, I just think that's too many "if"s to build a product roadmap on. It can turn into that in a couple of years, but anyone building a complex SoC today is better off assuming it won't come to that IMHO. Arnd
next prev parent reply other threads:[~2013-11-19 16:19 UTC|newest] Thread overview: 186+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-11-15 1:44 ACPI vs DT at runtime Olof Johansson 2013-11-15 1:44 ` Olof Johansson 2013-11-15 9:57 ` Mark Rutland 2013-11-15 9:57 ` Mark Rutland [not found] ` <20131115175241. GB27174@quad.lixom.net> [not found] ` <20131115095717.GC1709-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-15 17:52 ` Olof Johansson 2013-11-15 17:52 ` Olof Johansson 2013-11-15 18:13 ` David Goodenough 2013-11-21 16:15 ` Grant Likely 2013-11-18 17:47 ` Jon Masters 2013-11-18 17:47 ` Jon Masters [not found] ` <20131115175241.GB27174-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-15 18:08 ` Russell King - ARM Linux 2013-11-15 18:08 ` Russell King - ARM Linux [not found] ` <20131115180832.GR16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-15 18:42 ` Olof Johansson 2013-11-15 18:42 ` Olof Johansson 2013-11-15 19:56 ` Arnd Bergmann 2013-11-15 19:56 ` Arnd Bergmann [not found] ` <201311152056.47846.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-15 23:21 ` Russell King - ARM Linux 2013-11-15 23:21 ` Russell King - ARM Linux [not found] ` <20131115232109.GT16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-18 15:05 ` Arnd Bergmann 2013-11-18 15:05 ` Arnd Bergmann [not found] ` <201311181605.37300.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-18 15:19 ` Russell King - ARM Linux 2013-11-18 15:19 ` Russell King - ARM Linux 2013-11-18 15:46 ` Arnd Bergmann 2013-11-18 15:46 ` Arnd Bergmann 2013-11-21 16:10 ` Grant Likely 2013-11-21 16:10 ` Grant Likely [not found] ` <20131121161037.C528CC406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-21 18:26 ` Arnd Bergmann 2013-11-21 18:26 ` Arnd Bergmann 2013-11-21 19:40 ` Mark Brown 2013-11-21 19:40 ` Mark Brown [not found] ` <20131118151900.GF16735@ n2100.arm.linux.org.uk> [not found] ` <20131118151900.GF16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 16:11 ` Grant Likely 2013-11-21 16:11 ` Grant Likely 2013-11-21 16:00 ` Grant Likely 2013-11-21 16:00 ` Grant Likely 2013-11-19 11:30 ` Mark Rutland 2013-11-19 11:30 ` Mark Rutland 2013-11-19 11:35 ` Mark Rutland 2013-11-19 11:35 ` Mark Rutland [not found] ` <20131119113557.GI5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 11:51 ` Leif Lindholm 2013-11-19 11:51 ` Leif Lindholm [not found] ` <20131119113015.GH5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 11:57 ` Russell King - ARM Linux 2013-11-19 11:57 ` Russell King - ARM Linux 2013-11-19 13:56 ` Stefano Stabellini 2013-11-19 13:56 ` Stefano Stabellini 2013-11-19 14:38 ` Mark Rutland 2013-11-19 14:38 ` Mark Rutland [not found] ` <20131119143840.GN5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 14:59 ` Leif Lindholm 2013-11-19 14:59 ` Leif Lindholm 2013-11-19 18:23 ` Olof Johansson 2013-11-19 18:23 ` Olof Johansson 2013-11-19 14:05 ` Arnd Bergmann 2013-11-19 14:05 ` Arnd Bergmann 2013-11-19 15:21 ` Mark Rutland 2013-11-19 15:21 ` Mark Rutland [not found] ` <20131119152157.GO5914-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2013-11-19 16:19 ` Arnd Bergmann [this message] 2013-11-19 16:19 ` Arnd Bergmann 2013-11-19 18:34 ` Olof Johansson 2013-11-19 18:34 ` Olof Johansson 2013-11-19 19:06 ` Tom Rini 2013-11-19 19:06 ` Tom Rini 2013-11-19 18:19 ` Olof Johansson 2013-11-19 18:19 ` Olof Johansson [not found] ` <20131119181959.GA20967-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-21 16:37 ` Grant Likely 2013-11-21 16:37 ` Grant Likely 2013-11-21 16:29 ` Grant Likely 2013-11-21 16:29 ` Grant Likely [not found] ` <20131121170122. GB22960@srcf.ucam.org> [not found] ` <20131121170122.GB22960-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> 2013-11-21 18:38 ` Grant Likely 2013-11-21 18:38 ` Grant Likely [not found] ` <20131121162944.F087FC406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-21 17:01 ` Matthew Garrett 2013-11-21 17:01 ` Matthew Garrett 2013-11-21 17:58 ` Olof Johansson 2013-11-21 17:58 ` Olof Johansson [not found] ` <20131121175822.GA9590-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-21 18:19 ` Matthew Garrett 2013-11-21 18:19 ` Matthew Garrett 2013-11-21 18:33 ` Arnd Bergmann 2013-11-21 18:33 ` Arnd Bergmann 2013-11-21 18:54 ` Russell King - ARM Linux 2013-11-21 18:54 ` Russell King - ARM Linux [not found] ` <20131121185408.GX16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 18:59 ` Olof Johansson 2013-11-21 18:59 ` Olof Johansson [not found] ` <CAOesGMgzUSMDy99XojipfRd5OM88UhfbCYO0aoc5m-Q8Fwnddg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-21 19:01 ` Russell King - ARM Linux 2013-11-21 19:01 ` Russell King - ARM Linux [not found] ` <20131121190126.GZ16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 19:31 ` Olof Johansson 2013-11-21 19:31 ` Olof Johansson [not found] ` < CAOesGMgzUSMDy99XojipfRd5OM88UhfbCYO0aoc5m-Q8Fwnddg@mail.gmail.com> [not found] ` < 20131121190126.GZ16735@n2100.arm.linux.org.uk> [not found] ` < CAOesGMgxGq1Zmo+Dq-Rmy2F02-=12yUzB0AKn35yK2j3CacNRQ@mail.gmail.com> [not found] ` <CAOesGMgxGq1Zmo+Dq-Rmy2F02-=12yUzB0AKn35yK2j3CacNRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-21 20:44 ` Grant Likely 2013-11-21 20:44 ` Grant Likely 2013-11-21 18:53 ` Mark Brown 2013-11-21 18:53 ` Mark Brown 2013-11-15 18:28 ` Jason Gunthorpe 2013-11-15 18:28 ` Jason Gunthorpe [not found] ` <20131115182826.GB14920-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2013-11-15 18:57 ` Arnd Bergmann 2013-11-15 18:57 ` Arnd Bergmann 2013-11-20 13:49 ` Grant Likely 2013-11-20 13:49 ` Grant Likely [not found] ` <20131120134942.95DBFC4079D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-20 17:43 ` Stefano Stabellini 2013-11-20 17:43 ` Stefano Stabellini [not found] ` <alpine.DEB.2.02.1311201737410.3198-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org> 2013-11-20 17:47 ` Olof Johansson 2013-11-20 17:47 ` Olof Johansson 2013-11-18 5:19 ` Jon Masters 2013-11-18 5:26 ` Jon Masters [not found] ` <5289A4F3.5040203-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 19:25 ` Olof Johansson 2013-11-18 19:25 ` Olof Johansson [not found] ` <20131118192552.GD5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-18 20:43 ` Jon Masters 2013-11-18 20:43 ` Jon Masters [not found] ` <528A7BFD.4020303-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 21:25 ` Olof Johansson 2013-11-18 21:25 ` Olof Johansson 2013-11-18 7:22 ` Richard Cochran 2013-11-18 13:55 ` Stefano Stabellini 2013-11-18 15:00 ` Mark Brown [not found] ` <20131118150052.GC24408-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2013-11-18 19:13 ` Olof Johansson 2013-11-18 19:13 ` Olof Johansson [not found] ` <20131118191336.GB5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-19 9:12 ` Richard Cochran 2013-11-19 9:12 ` Richard Cochran 2013-11-19 18:48 ` Olof Johansson 2013-11-19 18:48 ` Olof Johansson [not found] ` <20131119184827.GD20967-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-20 6:40 ` Richard Cochran 2013-11-20 6:40 ` Richard Cochran 2013-11-21 18:16 ` Grant Likely 2013-11-21 18:16 ` Grant Likely 2013-11-21 19:21 ` Russell King - ARM Linux 2013-11-21 19:21 ` Russell King - ARM Linux [not found] ` < 20131121192136.GA16735@n2100.arm.linux.org.uk> [not found] ` <20131121192136.GA16735-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2013-11-21 20:47 ` Grant Likely 2013-11-21 20:47 ` Grant Likely [not found] ` <20131121204704.E4487C40753-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2013-11-22 11:43 ` Catalin Marinas 2013-11-22 11:43 ` Catalin Marinas [not found] ` <CAHkRjk5MstjD9JFk+co8k89i8geJBmSF6uObhGdmWSe0GJHo8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-22 12:00 ` Pantelis Antoniou 2013-11-22 12:00 ` Pantelis Antoniou [not found] ` <97692EF2-013E-4E4B-BC16-E0915D67EFEC-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> 2014-05-05 7:06 ` Alexander Holler 2014-05-05 7:06 ` Alexander Holler [not found] ` <53673866.9000105-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> 2014-05-05 14:41 ` Arnd Bergmann 2014-05-05 14:41 ` Arnd Bergmann 2014-05-05 15:29 ` Alexander Holler 2014-05-05 15:29 ` Alexander Holler [not found] ` <5367AE6B.3010105-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> 2014-05-05 17:29 ` Arnd Bergmann 2014-05-05 17:29 ` Arnd Bergmann 2014-05-06 15:37 ` Grant Likely 2014-05-06 15:37 ` Grant Likely 2014-05-06 15:27 ` Grant Likely 2014-05-06 15:27 ` Grant Likely [not found] ` <20140506152725.E5B90C40959-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org> 2014-05-06 16:32 ` Olof Johansson 2014-05-06 16:32 ` Olof Johansson 2013-11-18 15:28 ` Rob Herring [not found] ` <5289A356.4060004-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 19:09 ` Olof Johansson 2013-11-18 19:09 ` Olof Johansson [not found] ` <20131118190929.GA5886-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org> 2013-11-18 20:54 ` Jon Masters 2013-11-18 20:54 ` Jon Masters [not found] ` <528A7EA0.9050101-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 21:50 ` Olof Johansson 2013-11-18 21:50 ` Olof Johansson 2013-11-18 21:32 ` Grant Likely 2013-11-18 21:32 ` Grant Likely 2013-11-18 22:47 ` David Goodenough 2013-11-19 12:48 ` Arnd Bergmann 2013-11-19 12:48 ` Arnd Bergmann 2013-11-19 13:34 ` David Goodenough 2013-11-19 16:52 ` Arnd Bergmann 2013-11-21 18:23 ` Grant Likely 2013-11-19 14:33 ` Grant Likely [not found] ` <CAOesGMjKeRb=fFJM0MabDihbEiCGM4EqW9D5i_6-RFxTnpB4Qw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-15 20:58 ` Arnd Bergmann 2013-11-15 20:58 ` Arnd Bergmann [not found] ` <201311152158.32644.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-15 21:44 ` Olof Johansson 2013-11-15 21:44 ` Olof Johansson [not found] ` <CAOesGMhkCn2zeJj_ZZAZu_wJya-4evWEqNHpVJEpjxzWHVWY3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-17 17:18 ` Stefano Stabellini 2013-11-17 17:18 ` Stefano Stabellini [not found] ` <alpine.DEB.2.02.1311171705130.4714-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org> 2013-11-17 18:10 ` Arnd Bergmann 2013-11-17 18:10 ` Arnd Bergmann [not found] ` < CAOesGMiYyOcvr3Aqs-p8zc=XDwJM9NZtNxtxrTZssc6F=siZCw@mail.gmail.com> 2013-11-17 22:20 ` Olof Johansson 2013-11-17 22:20 ` Olof Johansson [not found] ` <CAOesGMiYyOcvr3Aqs-p8zc=XDwJM9NZtNxtxrTZssc6F=siZCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-18 8:45 ` Arnd Bergmann 2013-11-18 8:45 ` Arnd Bergmann 2013-11-18 17:33 ` Jon Masters 2013-11-18 17:38 ` Russell King - ARM Linux [not found] ` <528A4F5F.7080104-Zp4isUonpHBD60Wz+7aTrA@public.gmane.org> 2013-11-18 19:21 ` Olof Johansson 2013-11-18 19:21 ` Olof Johansson 2013-11-21 18:26 ` Grant Likely 2013-11-18 15:04 ` Mark Brown 2013-11-18 15:04 ` Mark Brown 2013-11-18 15:10 ` Arnd Bergmann 2013-11-18 15:10 ` Arnd Bergmann [not found] ` < 201311181610.33105.arnd@arndb.de> [not found] ` <201311181610.33105.arnd-r2nGTMty4D4@public.gmane.org> 2013-11-18 21:38 ` Grant Likely 2013-11-18 21:38 ` Grant Likely 2013-11-18 23:25 ` Leif Lindholm 2013-11-18 23:25 ` Leif Lindholm [not found] ` <20131118232536.GF1567-GZEopFhza0F985/tl1ce8aaDwS/vmuI7@public.gmane.org> 2013-11-18 23:29 ` Olof Johansson 2013-11-18 23:29 ` Olof Johansson [not found] ` <CAOesGMh373ZsLzoGHJm+xV3uFVjh2CBSA8SXY4PA+VxL3a5W1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-11-18 23:34 ` Leif Lindholm 2013-11-18 23:34 ` Leif Lindholm
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=201311191719.39788.arnd@arndb.de \ --to=arnd-r2ngtmty4d4@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \ --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.