On 03/03/2015 05:20 PM, Cyril Bur wrote:
On Tue, 2015-03-03 at 15:15 -0800, Tyrel Datwyler wrote:
On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
On 03/01/2015 09:20 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the
On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
On 03/01/2015 09:20 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
On Tue, 2015-03-03 at 15:15 -0800, Tyrel Datwyler wrote:
On 03/02/2015 01:49 PM, Tyrel Datwyler wrote:
On 03/01/2015 09:20 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the kernel after resuming
from a suspend
On 03/01/2015 09:20 PM, Cyril Bur wrote:
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
that of the hypervisor. The code as it stands
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
that of the hypervisor. The code as it stands is not endian safe as it relies
on
We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
that of the hypervisor. The code as it stands is not endian safe as it relies
on parsing buffers returned by RTAS calls that thusly contains data
