From: Jason Cooper <jason@lakedaemon.net> To: Jon Masters <jcm@redhat.com> Cc: Mark Brown <broonie@kernel.org>, Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org, Catalin Marinas <catalin.marinas@arm.com>, Rob Herring <robh@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, Robert Richter <rric@kernel.org>, "linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>, Marc Zyngier <Marc.Zyngier@arm.com>, Daniel Lezcano <daniel.lezcano@linaro.org>, Liviu Dudau <Liviu.Dudau@arm.com>, Robert Moore <robert.moore@intel.com>, Will Deacon <Will.Deacon@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Lv Zheng <lv.zheng@intel.com>, Bjorn Helgaas <bhelgaas@google.com>, Olof Johansson <olof@lixom.net> Subject: Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64 Date: Wed, 7 Jan 2015 16:40:55 -0500 [thread overview] Message-ID: <20150107214055.GP24989@titan.lakedaemon.net> (raw) In-Reply-To: <54AD8FF2.60407@redhat.com> On Wed, Jan 07, 2015 at 02:58:42PM -0500, Jon Masters wrote: > On 01/07/2015 01:41 PM, Jason Cooper wrote: > > On Wed, Jan 07, 2015 at 05:27:41PM +0000, Mark Brown wrote: > >> On Wed, Jan 07, 2015 at 02:06:28PM +0100, Arnd Bergmann wrote: > >>> On Wednesday 07 January 2015 11:50:39 Catalin Marinas wrote: > >> > >>>> From what I gathered so far, the main reason for _some_ vendors is not > >>>> support for "other" OS but actually features that ACPI has and DT > >>>> doesn't (like AML; I deliberately ignore statements like "industry > >>>> standard"). _If_ such reasons are sound, maybe they have a case for > >>>> ACPI-only machines targeted primarily at Linux. > >> > >>> What I got from the replies from HP, Huawei and from earlier discussions > >>> with Jon is that they all hope to get to the point of relying on AML > >>> alone to bridge the differences between SoC families. However, I don't > >>> see that happening with the limited hardware compatibility that the > >>> existing SBSA provides: > >> > >> I tend to agree with you that it's an overreach to think that this is > >> going to completely abstract away the differences between SoCs from > >> different vendors without substantial further standardization work. > >> However it does seem reasonable to expect that features like AML are > >> going to be more successful in handling board differences and > >> incremental revisions of SoCs - things like interactions with system > >> power controllers for example. That seems like a useful win in and of > >> itself, and one that's worth supporting. > > > > This piqued my interest, so I did a little research and found the > > following to describe AML (second para under "What does this mean?") > > > > http://community.arm.com/groups/processors/blog/2014/05/01/let-s-talk-acpi-for-servers > > > > iiuc, AML are basically drivers for some low-level functions provided as > > binary blobs via the ACPI tables. > > AML isn't a "driver" per se. Think of it as providing a couple of > methods for doing things like turning on a device, where the interpreted > code might cause e.g. a memory address to be written with a value that > causes a side effect (e.g. talking with a system configuration > co-processor hidden inside the SoC the adjusts the clocking, enables > power, configures PHY parameters, etc.). Most of the "AML" that you see > on servers is actually just informational, or methods that return data > describing the hardware installed. So, similar in scope to an irqchip driver? Because that's what I was thinking when I said "driver", not alsa or drm... Thanks for great description. > > How does this work in a trusted boot scenario? > > No different than on x86. Suprisingly, I don't do much with x86 development-wise. The x86 boxes are just tools to me. So I'm not very familiar with the intricacies there. Do you have a pointer to ACPI update security standards/protocols? > > Can the ACPI tables, and these binary blobs with it, be updated from userspace? > > Tables are baked into the firmware and are updated as a result of normal > firmware updates (which already has a defined process). There are > secondary tables that can augment things like the primary DSDT but those > are also provided by the platform. There are only two ways the "OS" > might provide a DSDT, but only including here for pedantry: > > 1). If you compile a kernel specially with an embedded DSDT within the > image itself (nobody does this one any more AFAIK). > > 2). If you attach a special update test DSDT into your initramfs in a > particular way, in which case I believe secure boot already is disabled. > > But these are all developer/debug things, not intended for users running > in a secure boot environment. Right, I'm more concerned about the update process being the vector to inject bad code. > > If so, is there an authentication mechanism (including for non-secure boot scenarios)? > > It's no different than scenarios on x86, which are well covered. > > > One of the reasons I've really enjoyed working with ARM platforms and DT > > is the absence of this type of 'feature'. I honestly don't care whether > > the kernel gets the board configuration info from DT or ACPI or FOO, as > > long as we can avoid the security mistakes of the past: > > > > http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors-for-numerous-devices-a-940994.html > > ACPI is not the great satan. Relax, I'm not saying, nor implying that. :) I *am* saying that upgradeable executable code not loaded from traditional OS storage (harddisk, flash) is a valid security concern. > I'm aware certain others in the community have written missinformed > blog posts and G+ rants equating ACPI with SMI and even with various > other system firmware. You're in luck, I don't blog or do social media. :-P > I can't force someone to become informed on a topic, especially if > it's politically useful to them to hate on ACPI and use the security > paranoia handwavy argument. I'm not sure where you got that from. I said very specifically, since trimmed, that I don't care where the board configuration data comes from, DT, ACPI, or FOO. If ACPI works, is stable, and integrates with the community, I'd use it. Right now, DT is the closest to that goal, so it's what I prefer. > > I'm not advocating "throw out AML and ACPI with it!", rather I'd like to > > see a serious, open, discussion about the security implications of a > > convenience feature such as AML. > > AML is in (almost) every server you're using today. "It's already everywhere" is not a valid reason to dismiss a security discussion. It's *not* on ARM today, so AML on ARM is a significant change to ecosystem. I'd hope I'm not the only person who was taking advantage of fewer firmware hiding spots that ARM provides. :) > What you want to be worried about is hidden firmware, especially what > might be running inside a Trusted environment or inside an SMI > context, or the radio firmware on your phone that the NSA have > backdoored. These are all valid security concerns, but this thread was about ACPI/AML on ARM, so I didn't mention them. Just because there are three other holes doesn't mean we should throw up our hands and not address the one in front of us. > Once we've solved every other issue, we can come back to whether the > extremely limited capabilities of AML are what the evil bad guys are > using to infiltrate our minds and make us think that we all want to > use ACPI. Umm, wow. I was not implying that a malicious piece of code would call AML in a bad way to do something nefarious. I *am* concerned about a malicious update to the ACPI tables hooking an innocent AML call so that *any* malicious code could be run at boot time, or suspend/resume, shutdown, etc. Sorry to have plucked a nerve, but I am sincerely interested in having a *rational* discussion about how this changes the ARM ecosystem. fwiw, if I didn't think this was going to hit mainline, I wouldn't've bothered bringing it up. ;-) thx, Jason.
WARNING: multiple messages have this Message-ID (diff)
From: jason@lakedaemon.net (Jason Cooper) To: linux-arm-kernel@lists.infradead.org Subject: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64 Date: Wed, 7 Jan 2015 16:40:55 -0500 [thread overview] Message-ID: <20150107214055.GP24989@titan.lakedaemon.net> (raw) In-Reply-To: <54AD8FF2.60407@redhat.com> On Wed, Jan 07, 2015 at 02:58:42PM -0500, Jon Masters wrote: > On 01/07/2015 01:41 PM, Jason Cooper wrote: > > On Wed, Jan 07, 2015 at 05:27:41PM +0000, Mark Brown wrote: > >> On Wed, Jan 07, 2015 at 02:06:28PM +0100, Arnd Bergmann wrote: > >>> On Wednesday 07 January 2015 11:50:39 Catalin Marinas wrote: > >> > >>>> From what I gathered so far, the main reason for _some_ vendors is not > >>>> support for "other" OS but actually features that ACPI has and DT > >>>> doesn't (like AML; I deliberately ignore statements like "industry > >>>> standard"). _If_ such reasons are sound, maybe they have a case for > >>>> ACPI-only machines targeted primarily at Linux. > >> > >>> What I got from the replies from HP, Huawei and from earlier discussions > >>> with Jon is that they all hope to get to the point of relying on AML > >>> alone to bridge the differences between SoC families. However, I don't > >>> see that happening with the limited hardware compatibility that the > >>> existing SBSA provides: > >> > >> I tend to agree with you that it's an overreach to think that this is > >> going to completely abstract away the differences between SoCs from > >> different vendors without substantial further standardization work. > >> However it does seem reasonable to expect that features like AML are > >> going to be more successful in handling board differences and > >> incremental revisions of SoCs - things like interactions with system > >> power controllers for example. That seems like a useful win in and of > >> itself, and one that's worth supporting. > > > > This piqued my interest, so I did a little research and found the > > following to describe AML (second para under "What does this mean?") > > > > http://community.arm.com/groups/processors/blog/2014/05/01/let-s-talk-acpi-for-servers > > > > iiuc, AML are basically drivers for some low-level functions provided as > > binary blobs via the ACPI tables. > > AML isn't a "driver" per se. Think of it as providing a couple of > methods for doing things like turning on a device, where the interpreted > code might cause e.g. a memory address to be written with a value that > causes a side effect (e.g. talking with a system configuration > co-processor hidden inside the SoC the adjusts the clocking, enables > power, configures PHY parameters, etc.). Most of the "AML" that you see > on servers is actually just informational, or methods that return data > describing the hardware installed. So, similar in scope to an irqchip driver? Because that's what I was thinking when I said "driver", not alsa or drm... Thanks for great description. > > How does this work in a trusted boot scenario? > > No different than on x86. Suprisingly, I don't do much with x86 development-wise. The x86 boxes are just tools to me. So I'm not very familiar with the intricacies there. Do you have a pointer to ACPI update security standards/protocols? > > Can the ACPI tables, and these binary blobs with it, be updated from userspace? > > Tables are baked into the firmware and are updated as a result of normal > firmware updates (which already has a defined process). There are > secondary tables that can augment things like the primary DSDT but those > are also provided by the platform. There are only two ways the "OS" > might provide a DSDT, but only including here for pedantry: > > 1). If you compile a kernel specially with an embedded DSDT within the > image itself (nobody does this one any more AFAIK). > > 2). If you attach a special update test DSDT into your initramfs in a > particular way, in which case I believe secure boot already is disabled. > > But these are all developer/debug things, not intended for users running > in a secure boot environment. Right, I'm more concerned about the update process being the vector to inject bad code. > > If so, is there an authentication mechanism (including for non-secure boot scenarios)? > > It's no different than scenarios on x86, which are well covered. > > > One of the reasons I've really enjoyed working with ARM platforms and DT > > is the absence of this type of 'feature'. I honestly don't care whether > > the kernel gets the board configuration info from DT or ACPI or FOO, as > > long as we can avoid the security mistakes of the past: > > > > http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors-for-numerous-devices-a-940994.html > > ACPI is not the great satan. Relax, I'm not saying, nor implying that. :) I *am* saying that upgradeable executable code not loaded from traditional OS storage (harddisk, flash) is a valid security concern. > I'm aware certain others in the community have written missinformed > blog posts and G+ rants equating ACPI with SMI and even with various > other system firmware. You're in luck, I don't blog or do social media. :-P > I can't force someone to become informed on a topic, especially if > it's politically useful to them to hate on ACPI and use the security > paranoia handwavy argument. I'm not sure where you got that from. I said very specifically, since trimmed, that I don't care where the board configuration data comes from, DT, ACPI, or FOO. If ACPI works, is stable, and integrates with the community, I'd use it. Right now, DT is the closest to that goal, so it's what I prefer. > > I'm not advocating "throw out AML and ACPI with it!", rather I'd like to > > see a serious, open, discussion about the security implications of a > > convenience feature such as AML. > > AML is in (almost) every server you're using today. "It's already everywhere" is not a valid reason to dismiss a security discussion. It's *not* on ARM today, so AML on ARM is a significant change to ecosystem. I'd hope I'm not the only person who was taking advantage of fewer firmware hiding spots that ARM provides. :) > What you want to be worried about is hidden firmware, especially what > might be running inside a Trusted environment or inside an SMI > context, or the radio firmware on your phone that the NSA have > backdoored. These are all valid security concerns, but this thread was about ACPI/AML on ARM, so I didn't mention them. Just because there are three other holes doesn't mean we should throw up our hands and not address the one in front of us. > Once we've solved every other issue, we can come back to whether the > extremely limited capabilities of AML are what the evil bad guys are > using to infiltrate our minds and make us think that we all want to > use ACPI. Umm, wow. I was not implying that a malicious piece of code would call AML in a bad way to do something nefarious. I *am* concerned about a malicious update to the ACPI tables hooking an innocent AML call so that *any* malicious code could be run at boot time, or suspend/resume, shutdown, etc. Sorry to have plucked a nerve, but I am sincerely interested in having a *rational* discussion about how this changes the ARM ecosystem. fwiw, if I didn't think this was going to hit mainline, I wouldn't've bothered bringing it up. ;-) thx, Jason.
next prev parent reply other threads:[~2015-01-07 21:41 UTC|newest] Thread overview: 297+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-10-17 13:36 [PATCH v5 00/18] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo 2014-10-17 13:36 ` Hanjun Guo 2014-10-17 13:36 ` [PATCH v5 01/18] ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() Hanjun Guo 2014-10-17 13:36 ` Hanjun Guo 2014-11-18 13:45 ` Hanjun Guo 2014-11-18 13:45 ` Hanjun Guo 2014-11-18 13:45 ` Hanjun Guo 2014-11-18 16:43 ` Catalin Marinas 2014-11-18 16:43 ` Catalin Marinas 2014-11-18 16:43 ` Catalin Marinas 2014-11-18 16:57 ` Will Deacon 2014-11-18 16:57 ` Will Deacon 2014-11-18 16:57 ` Will Deacon 2014-11-18 17:02 ` Sudeep Holla 2014-11-18 17:02 ` Sudeep Holla 2014-11-18 17:02 ` Sudeep Holla 2014-11-18 17:03 ` Will Deacon 2014-11-18 17:03 ` Will Deacon 2014-11-18 17:03 ` Will Deacon 2014-11-19 0:29 ` Hanjun Guo 2014-11-19 0:29 ` Hanjun Guo 2014-11-19 0:29 ` Hanjun Guo 2014-10-17 13:36 ` [PATCH v5 02/18] ACPI / table: Add new function to get table entries Hanjun Guo 2014-10-17 13:36 ` Hanjun Guo 2014-10-17 13:36 ` Hanjun Guo 2014-11-24 1:27 ` Rafael J. Wysocki 2014-11-24 1:27 ` Rafael J. Wysocki 2014-11-24 1:27 ` Rafael J. Wysocki 2014-11-24 11:03 ` Hanjun Guo 2014-11-24 11:03 ` Hanjun Guo 2014-11-24 11:03 ` Hanjun Guo 2014-11-24 14:51 ` Rafael J. Wysocki 2014-11-24 14:51 ` Rafael J. Wysocki 2014-11-24 14:51 ` Rafael J. Wysocki 2014-11-25 3:38 ` Hanjun Guo 2014-11-25 3:38 ` Hanjun Guo 2014-11-25 3:38 ` Hanjun Guo 2014-11-25 21:20 ` Rafael J. Wysocki 2014-11-25 21:20 ` Rafael J. Wysocki 2014-11-25 21:20 ` Rafael J. Wysocki 2014-11-26 1:42 ` Hanjun Guo 2014-11-26 1:42 ` Hanjun Guo 2014-11-26 1:42 ` Hanjun Guo 2014-10-17 13:36 ` [PATCH v5 03/18] ACPI / table: Count matched and successfully parsed entries without specifying max entries Hanjun Guo 2014-10-17 13:36 ` Hanjun Guo 2014-11-18 13:51 ` Hanjun Guo 2014-11-18 13:51 ` Hanjun Guo 2014-11-18 13:51 ` Hanjun Guo 2014-11-18 20:15 ` Rafael J. Wysocki 2014-11-18 20:15 ` Rafael J. Wysocki 2014-11-18 20:15 ` Rafael J. Wysocki 2014-11-19 0:34 ` Hanjun Guo 2014-11-19 0:34 ` Hanjun Guo 2014-11-19 0:34 ` Hanjun Guo 2014-11-24 1:45 ` Rafael J. Wysocki 2014-11-24 1:45 ` Rafael J. Wysocki 2014-11-24 1:45 ` Rafael J. Wysocki 2014-11-24 8:34 ` Tomasz Nowicki 2014-11-24 8:34 ` Tomasz Nowicki 2014-11-24 8:34 ` Tomasz Nowicki 2014-11-24 15:16 ` Rafael J. Wysocki 2014-11-24 15:16 ` Rafael J. Wysocki 2014-11-24 15:16 ` Rafael J. Wysocki 2014-11-24 15:01 ` Tomasz Nowicki 2014-11-24 15:01 ` Tomasz Nowicki 2014-11-24 15:01 ` Tomasz Nowicki 2014-11-24 15:37 ` Rafael J. Wysocki 2014-11-24 15:37 ` Rafael J. Wysocki 2014-11-24 15:37 ` Rafael J. Wysocki 2014-11-24 15:18 ` Tomasz Nowicki 2014-11-24 15:18 ` Tomasz Nowicki 2014-11-24 15:18 ` Tomasz Nowicki 2014-10-17 13:37 ` [PATCH v5 04/18] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 05/18] ARM64 / ACPI: Introduce sleep-arm.c Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 06/18] ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 07/18] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 08/18] ARM64 / ACPI: Make PCI optional for ACPI on ARM64 Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 09/18] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 10/18] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 11/18] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 12/18] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-24 17:39 ` Lorenzo Pieralisi 2014-10-24 17:39 ` Lorenzo Pieralisi 2014-10-24 17:39 ` Lorenzo Pieralisi 2014-10-27 9:58 ` Hanjun Guo 2014-10-27 9:58 ` Hanjun Guo 2014-10-27 9:58 ` Hanjun Guo 2014-10-29 10:43 ` Lorenzo Pieralisi 2014-10-29 10:43 ` Lorenzo Pieralisi 2014-10-29 10:43 ` Lorenzo Pieralisi 2014-10-30 8:27 ` Hanjun Guo 2014-10-30 8:27 ` Hanjun Guo 2014-10-30 8:27 ` Hanjun Guo 2014-10-29 21:33 ` Rafael J. Wysocki 2014-10-29 21:33 ` Rafael J. Wysocki 2014-10-29 21:33 ` Rafael J. Wysocki 2014-10-30 8:30 ` Hanjun Guo 2014-10-30 8:30 ` Hanjun Guo 2014-10-30 8:30 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 13/18] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 14/18] ARM64 / ACPI: Add GICv2 specific ACPI boot support Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 15/18] ARM64 / ACPI: Parse GTDT to initialize arch timer Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 16/18] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 17/18] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-10-17 13:37 ` [PATCH v5 18/18] Documentation: ACPI for ARM64 Hanjun Guo 2014-10-17 13:37 ` Hanjun Guo 2014-12-18 20:01 ` Suravee Suthikulanit 2014-12-18 20:01 ` Suravee Suthikulanit 2014-12-18 20:01 ` Suravee Suthikulanit 2014-12-19 13:04 ` Hanjun Guo 2014-12-19 13:04 ` Hanjun Guo 2014-12-19 13:04 ` Hanjun Guo 2014-12-18 20:04 ` Timur Tabi 2014-12-18 20:04 ` Timur Tabi 2014-12-18 20:04 ` Timur Tabi 2014-12-19 13:53 ` Hanjun Guo 2014-12-19 13:53 ` Hanjun Guo 2014-12-19 13:53 ` Hanjun Guo 2014-12-24 17:18 ` Catalin Marinas 2014-12-24 17:18 ` Catalin Marinas 2014-12-24 17:18 ` Catalin Marinas 2014-12-24 19:33 ` Jon Masters 2014-12-24 19:33 ` Jon Masters 2014-12-24 19:33 ` Jon Masters 2014-12-26 13:23 ` Mark Brown 2014-12-26 13:23 ` Mark Brown 2014-12-26 13:23 ` Mark Brown 2014-12-30 11:23 ` Hanjun Guo 2014-12-30 11:23 ` Hanjun Guo 2014-12-30 11:23 ` Hanjun Guo 2015-01-05 13:13 ` Catalin Marinas 2015-01-05 13:13 ` Catalin Marinas 2015-01-05 13:13 ` Catalin Marinas 2015-01-05 20:16 ` Arnd Bergmann 2015-01-05 20:16 ` Arnd Bergmann 2015-01-05 20:16 ` Arnd Bergmann 2015-01-06 11:20 ` Catalin Marinas 2015-01-06 11:20 ` Catalin Marinas 2015-01-06 11:20 ` Catalin Marinas 2015-01-06 13:51 ` G Gregory 2015-01-06 13:51 ` G Gregory 2015-01-06 13:51 ` G Gregory 2015-01-06 14:03 ` Catalin Marinas 2015-01-06 14:03 ` Catalin Marinas 2015-01-06 14:03 ` Catalin Marinas 2015-01-06 13:59 ` [Linaro-acpi] " Arnd Bergmann 2015-01-06 13:59 ` Arnd Bergmann 2015-01-06 13:59 ` Arnd Bergmann 2015-01-06 14:11 ` Catalin Marinas 2015-01-06 14:11 ` Catalin Marinas 2015-01-06 14:11 ` Catalin Marinas 2015-01-06 19:30 ` Arnd Bergmann 2015-01-06 19:30 ` Arnd Bergmann 2015-01-06 19:30 ` Arnd Bergmann 2015-01-15 14:10 ` Grant Likely 2015-01-15 14:10 ` Grant Likely 2015-01-15 14:10 ` Grant Likely 2015-01-15 15:51 ` Jon Masters 2015-01-15 15:51 ` Jon Masters 2015-01-15 15:51 ` Jon Masters 2015-01-15 16:52 ` Arnd Bergmann 2015-01-15 16:52 ` Arnd Bergmann 2015-01-15 16:52 ` Arnd Bergmann 2015-01-15 17:22 ` Al Stone 2015-01-15 17:22 ` Al Stone 2015-01-15 17:22 ` Al Stone 2015-01-16 16:35 ` Arnd Bergmann 2015-01-16 16:35 ` Arnd Bergmann 2015-01-16 16:35 ` Arnd Bergmann 2015-01-15 18:00 ` Mark Brown 2015-01-15 18:00 ` Mark Brown 2015-01-15 18:00 ` Mark Brown 2015-01-06 16:24 ` Jon Masters 2015-01-06 16:24 ` Jon Masters 2015-01-06 16:24 ` Jon Masters 2015-01-06 19:21 ` [Linaro-acpi] " Arnd Bergmann 2015-01-06 19:21 ` Arnd Bergmann 2015-01-06 19:21 ` Arnd Bergmann 2015-01-06 22:06 ` Jon Masters 2015-01-06 22:06 ` Jon Masters 2015-01-06 22:06 ` Jon Masters 2015-01-07 4:55 ` Jon Masters 2015-01-07 4:55 ` Jon Masters 2015-01-07 4:55 ` Jon Masters 2015-01-07 10:36 ` Arnd Bergmann 2015-01-07 10:36 ` Arnd Bergmann 2015-01-07 10:36 ` Arnd Bergmann 2015-01-07 11:50 ` Catalin Marinas 2015-01-07 11:50 ` Catalin Marinas 2015-01-07 11:50 ` Catalin Marinas 2015-01-07 13:06 ` Arnd Bergmann 2015-01-07 13:06 ` Arnd Bergmann 2015-01-07 17:27 ` Mark Brown 2015-01-07 17:27 ` Mark Brown 2015-01-07 17:44 ` Jon Masters 2015-01-07 17:44 ` Jon Masters 2015-01-07 19:48 ` Arnd Bergmann 2015-01-07 19:48 ` Arnd Bergmann 2015-01-07 20:05 ` Mark Brown 2015-01-07 20:05 ` Mark Brown 2015-01-07 20:14 ` Jon Masters 2015-01-07 20:14 ` Jon Masters 2015-01-07 20:14 ` Jon Masters 2015-01-09 10:33 ` Catalin Marinas 2015-01-09 10:33 ` Catalin Marinas 2015-01-09 10:33 ` Catalin Marinas 2015-01-09 10:55 ` Arnd Bergmann 2015-01-09 10:55 ` Arnd Bergmann 2015-01-09 10:55 ` Arnd Bergmann 2015-01-09 15:13 ` Catalin Marinas 2015-01-09 15:13 ` Catalin Marinas 2015-01-09 15:13 ` Catalin Marinas 2015-01-07 18:41 ` Jason Cooper 2015-01-07 18:41 ` Jason Cooper 2015-01-07 19:58 ` Jon Masters 2015-01-07 19:58 ` Jon Masters 2015-01-07 20:05 ` Jon Masters 2015-01-07 20:05 ` Jon Masters 2015-01-07 22:59 ` Jason Cooper 2015-01-07 22:59 ` Jason Cooper 2015-01-08 11:26 ` Arnd Bergmann 2015-01-08 11:26 ` Arnd Bergmann 2015-01-08 19:59 ` Kangkang Shen 2015-01-08 19:59 ` Kangkang Shen 2015-01-08 19:59 ` Kangkang Shen 2015-01-07 21:40 ` Jason Cooper [this message] 2015-01-07 21:40 ` Jason Cooper 2015-01-07 22:10 ` Jon Masters 2015-01-07 22:10 ` Jon Masters 2015-01-07 22:10 ` Jon Masters 2015-01-04 9:39 ` Hanjun Guo 2015-01-04 9:39 ` Hanjun Guo 2015-01-04 9:39 ` Hanjun Guo 2015-01-05 11:05 ` Catalin Marinas 2015-01-05 11:05 ` Catalin Marinas 2015-01-05 11:05 ` Catalin Marinas 2015-01-06 11:11 ` Hanjun Guo 2015-01-06 11:11 ` Hanjun Guo 2015-01-06 11:11 ` Hanjun Guo 2015-01-06 11:29 ` Catalin Marinas 2015-01-06 11:29 ` Catalin Marinas 2015-01-06 11:29 ` Catalin Marinas 2015-01-06 13:50 ` Hanjun Guo 2015-01-06 13:50 ` Hanjun Guo 2015-01-06 13:50 ` Hanjun Guo 2015-01-06 13:54 ` G Gregory 2015-01-06 13:54 ` G Gregory 2015-01-06 13:54 ` G Gregory 2015-01-06 13:59 ` Hanjun Guo 2015-01-06 13:59 ` Hanjun Guo 2015-01-06 13:59 ` Hanjun Guo 2015-01-06 14:05 ` Arnd Bergmann 2015-01-06 14:05 ` Arnd Bergmann 2015-01-06 14:05 ` Arnd Bergmann 2015-01-06 14:16 ` Catalin Marinas 2015-01-06 14:16 ` Catalin Marinas 2015-01-06 14:16 ` Catalin Marinas 2015-01-06 14:37 ` Charles Garcia-Tobin 2015-01-06 14:37 ` Charles Garcia-Tobin 2015-01-06 14:37 ` Charles Garcia-Tobin 2015-01-06 16:37 ` Jon Masters 2015-01-06 16:37 ` Jon Masters 2015-01-06 16:37 ` Jon Masters 2015-01-09 23:12 ` Arnd Bergmann 2015-01-09 23:12 ` Arnd Bergmann 2015-01-09 23:12 ` Arnd Bergmann [not found] ` <CAJ5Y-eZ5cu9_OhG24yAv+CZq7zKg0vU+eVGekyN+9dDzaz1OhQ@mail.gmail.com> 2014-12-30 20:13 ` ashwinc 2014-12-30 20:13 ` ashwinc at codeaurora.org 2014-12-31 8:34 ` Hanjun Guo 2014-12-31 8:34 ` Hanjun Guo 2014-12-31 8:34 ` Hanjun Guo 2014-12-31 15:08 ` ashwinc 2014-12-31 15:08 ` ashwinc at codeaurora.org 2014-12-31 15:08 ` ashwinc 2015-01-01 20:04 ` Graeme Gregory 2015-01-01 20:04 ` Graeme Gregory 2015-01-01 20:04 ` Graeme Gregory 2015-01-02 9:28 ` Hanjun Guo 2015-01-02 9:28 ` Hanjun Guo 2015-01-02 9:28 ` Hanjun Guo 2015-01-02 16:47 ` Catalin Marinas 2015-01-02 16:47 ` Catalin Marinas 2015-01-02 16:47 ` Catalin Marinas
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=20150107214055.GP24989@titan.lakedaemon.net \ --to=jason@lakedaemon.net \ --cc=Liviu.Dudau@arm.com \ --cc=Marc.Zyngier@arm.com \ --cc=Will.Deacon@arm.com \ --cc=arnd@arndb.de \ --cc=bhelgaas@google.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=daniel.lezcano@linaro.org \ --cc=jcm@redhat.com \ --cc=linaro-acpi@lists.linaro.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lv.zheng@intel.com \ --cc=olof@lixom.net \ --cc=rdunlap@infradead.org \ --cc=rjw@rjwysocki.net \ --cc=robert.moore@intel.com \ --cc=robh@kernel.org \ --cc=rric@kernel.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.