From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> To: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org> Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@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> Subject: Re: ACPI vs DT at runtime Date: Sun, 17 Nov 2013 19:10:51 +0100 [thread overview] Message-ID: <3371903.8j54vrCjEN@wuerfel> (raw) In-Reply-To: <alpine.DEB.2.02.1311171705130.4714-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org> On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > On Fri, 15 Nov 2013, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote: > > > On Friday 15 November 2013, Olof Johansson wrote: > > >> So, I'm strongly urging that whatever the server guys try to do, it > > >> will in the end result in the ACPI data being translated into DT > > >> equivalents, such that the kernel only needs to handle data via DT. > > > > > > I don't think that a translation layer is the answer, I see the problem > > > more in things that cannot be translated automatically. The parts that > > > are similar enough to allow translation could also just be handled by > > > a thin abstraction layer in the kernel, which I think we will see > > > on embedded x86 with DT-in-ACPI-syntax. > > > > I'm not so sure that converting everything yet again to another > > abstraction layer is a good solution. We've got one level of > > abstraction today -- DT. And we've got the un-abstracted layer of > > platform devices. Churning all drivers yet again seems like the wrong > > way to do this. For things that we can pre-populate instead of adding > > runtime abstraction, we should. My point was not that everything would be good if we change the kernel this way, it clearly wouldn't. I think the problem is more the parts for which neither an automated translation nor a unified driver level interface would work well. > Simply using DT would help avoiding the awkward situation where a driver > of a device only works with one of the two description formats and not > the other. Yes, but remember that Intel still have the problem on their embedded systems, and will want to solve them. For ARM Linux I agree that we're better off not having to change all the drivers again for this, but we will have a growing number of drivers that are shared with ACPI based x86 SoCs. At least there are only one or two vendors of those chips ;-) > > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > > > provide hand-written DT blobs for the few systems that start shipping > > > with that. > > > > I think we can do better -- we can ask those vendors to not ship ACPI > > at all, and ship DT themselves (together with us for review, etc). > > They can ship with ACPI if they want to, what is important is that they > ship with device tree too. > Encouraging them to do that is definitely the right thing to do today, > regardless of the medium to long term ACPI strategy for the Linux > kernel. I'm skeptical about getting people to ship both, except if they want to support multiple operating systems. For those vendors we are talking to, we are possibly able to convince them to drop ACPI for Linux based servers. The bigger problem is system vendors we don't talk to. They are going to to do any number of crazy things in their private kernels: * Board files * Hardcoded platform devices with no multiplatform support * Custom hypervisor (EL2 or EL3) interfaces for probing * FEX * ACPI * Some other firmware ported over from their MIPS products * Incompatible Open Firmware * Incompatible DT extensions * ... The only thing we really have a handle on is stuff that gets submitted for inclusion into Linux. One would hope that this would include any server platform, but I think the people trying get into that market are still learning about how to do these things. > > Especially since doing a broken ACPI implementation today _just for > > us_ will just distract them. If they need one for RT, fine. As I > > mentioned elsewhere, shipping a flashed DTB is no different from > > shipping ACPI from a future-proof point of view; we'll end up > > overriding either at some point once we figure out things better. > > Well said. +1 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: Sun, 17 Nov 2013 19:10:51 +0100 [thread overview] Message-ID: <3371903.8j54vrCjEN@wuerfel> (raw) In-Reply-To: <alpine.DEB.2.02.1311171705130.4714@kaball.uk.xensource.com> On Sunday 17 November 2013 17:18:03 Stefano Stabellini wrote: > On Fri, 15 Nov 2013, Olof Johansson wrote: > > On Fri, Nov 15, 2013 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > > On Friday 15 November 2013, Olof Johansson wrote: > > >> So, I'm strongly urging that whatever the server guys try to do, it > > >> will in the end result in the ACPI data being translated into DT > > >> equivalents, such that the kernel only needs to handle data via DT. > > > > > > I don't think that a translation layer is the answer, I see the problem > > > more in things that cannot be translated automatically. The parts that > > > are similar enough to allow translation could also just be handled by > > > a thin abstraction layer in the kernel, which I think we will see > > > on embedded x86 with DT-in-ACPI-syntax. > > > > I'm not so sure that converting everything yet again to another > > abstraction layer is a good solution. We've got one level of > > abstraction today -- DT. And we've got the un-abstracted layer of > > platform devices. Churning all drivers yet again seems like the wrong > > way to do this. For things that we can pre-populate instead of adding > > runtime abstraction, we should. My point was not that everything would be good if we change the kernel this way, it clearly wouldn't. I think the problem is more the parts for which neither an automated translation nor a unified driver level interface would work well. > Simply using DT would help avoiding the awkward situation where a driver > of a device only works with one of the two description formats and not > the other. Yes, but remember that Intel still have the problem on their embedded systems, and will want to solve them. For ARM Linux I agree that we're better off not having to change all the drivers again for this, but we will have a growing number of drivers that are shared with ACPI based x86 SoCs. At least there are only one or two vendors of those chips ;-) > > > I think we can still treat ACPI on ARM64 as a beginner's mistake and > > > provide hand-written DT blobs for the few systems that start shipping > > > with that. > > > > I think we can do better -- we can ask those vendors to not ship ACPI > > at all, and ship DT themselves (together with us for review, etc). > > They can ship with ACPI if they want to, what is important is that they > ship with device tree too. > Encouraging them to do that is definitely the right thing to do today, > regardless of the medium to long term ACPI strategy for the Linux > kernel. I'm skeptical about getting people to ship both, except if they want to support multiple operating systems. For those vendors we are talking to, we are possibly able to convince them to drop ACPI for Linux based servers. The bigger problem is system vendors we don't talk to. They are going to to do any number of crazy things in their private kernels: * Board files * Hardcoded platform devices with no multiplatform support * Custom hypervisor (EL2 or EL3) interfaces for probing * FEX * ACPI * Some other firmware ported over from their MIPS products * Incompatible Open Firmware * Incompatible DT extensions * ... The only thing we really have a handle on is stuff that gets submitted for inclusion into Linux. One would hope that this would include any server platform, but I think the people trying get into that market are still learning about how to do these things. > > Especially since doing a broken ACPI implementation today _just for > > us_ will just distract them. If they need one for RT, fine. As I > > mentioned elsewhere, shipping a flashed DTB is no different from > > shipping ACPI from a future-proof point of view; we'll end up > > overriding either at some point once we figure out things better. > > Well said. +1 Arnd
next prev parent reply other threads:[~2013-11-17 18:10 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 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 [this message] 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=3371903.8j54vrCjEN@wuerfel \ --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=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \ --cc=stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@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.