On 16/05/13 02:59, the mail apparently from Andrey Konovalov included:
On 05/15/2013 12:04 AM, Andrey Konovalov wrote:
https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule
The 13.05 linux-linaro release will be v3.10-rc2 based,
May 15: v3.10-rc1 based linux-linaro-core-track
On 05/15/2013 12:04 AM, Andrey Konovalov wrote:
https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule
The 13.05 linux-linaro release will be v3.10-rc2 based,
May 15: v3.10-rc1 based linux-linaro-core-tracking (llct) rebuild
* Done: the tag is llct-20130515.1
* Changes:
. the
On 05/15/2013 05:02 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2013-05-15 at 14:41 +0200, Ard Biesheuvel wrote:
On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
I see that the ARM version is following the pattern of SPARC64 and X86
SSSE3 in how it is configured, so for fear of opening a can of wor
Hi Liviu,
Regarding your comments about using the C-state instead of the residency,
we based off of the existing mcpm_suspend call which currently takes
residency (with a 0 meaning lowest power).
We used calls (including mcpm_suspend) in the hot plug/suspend path.
However, it does not know about
On Wed, 2013-05-15 at 09:49 -0700, Sebastian Capella wrote:
> Thanks Daniel!
>
> Liviu,
>
> I have been using on the linux-linaro branch in the linux-linaro-tracking
> repository here:
>
> https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/heads/linux-linaro
>
G
Thanks Daniel!
Liviu,
I have been using on the linux-linaro branch in the linux-linaro-tracking
repository here:
https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/heads/linux-linaro
Sorry for missing that.
Thanks!
Sebastian
On 15 May 2013 08:47, Daniel Lezca
On 05/15/2013 05:24 PM, Liviu Dudau wrote:
> Hi Sebastian,
>
> On Mon, May 13, 2013 at 07:53:42PM +0100, Sebastian Capella wrote:
>> Pass residency information to the mcpm_cpu_suspend. The information
>> is taken from the target_residency of the intended C-state.
>>
>> When a platform uses multip
Hi Sebastian,
On Mon, May 13, 2013 at 07:53:42PM +0100, Sebastian Capella wrote:
> Pass residency information to the mcpm_cpu_suspend. The information
> is taken from the target_residency of the intended C-state.
>
> When a platform uses multiple powerdown cstates, the residency information
> ind
This email is going to a rather wide audience so my apologies if it
isn't relevant to you.
If you don't use android.git.linaro.org or
review.android.git.linaro.org, you can ignore the rest of this email.
If you use either of these servers, please note that there will be
planned maintenance betwee
Fathi Boudra writes:
> On 14 May 2013 23:49, Kevin Hilman wrote:
>> Fathi Boudra writes:
>>
>> [...]
>>
Is there a way for us (linaro folks) to see more of the Jenkins setup
for these jobs (including the scripts.) There appears to be some useful
add-ons being used. Read-only acc
On Wed, 15 May 2013, Ard Biesheuvel wrote:
> On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
> > I see that the ARM version is following the pattern of SPARC64 and X86
> > SSSE3 in how it is configured, so for fear of opening a can of worms,
> > perhaps it's simpler if we just go with the linaro
On Wed, 2013-05-15 at 14:41 +0200, Ard Biesheuvel wrote:
> On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
> > I see that the ARM version is following the pattern of SPARC64 and X86
> > SSSE3 in how it is configured, so for fear of opening a can of worms,
> > perhaps it's simpler if we just go wi
On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
> I see that the ARM version is following the pattern of SPARC64 and X86
> SSSE3 in how it is configured, so for fear of opening a can of worms,
> perhaps it's simpler if we just go with the linaro-base.conf patch which
> started this thread? :-)
>
On Wed, 2013-05-15 at 14:12 +0200, Ard Biesheuvel wrote:
> On 15 May 2013 14:05, Jon Medhurst (Tixy) wrote:
> > If the assembler version is always faster I would have thought that we
> > should always have it enabled and not have it as a user visible option.
> > Perhaps the fact that the assembler
On 15 May 2013 14:05, Jon Medhurst (Tixy) wrote:
> If the assembler version is always faster I would have thought that we
> should always have it enabled and not have it as a user visible option.
> Perhaps the fact that the assembler is specifically target at ARMv4
> means that on ARMv7 CPUs the l
On Wed, 2013-05-15 at 10:17 +0200, Ard Biesheuvel wrote:
> On 14 May 2013 18:49, Jon Medhurst (Tixy) wrote:
> >
> > This also enables CONFIG_CRYPTO_SHA1 which we didn't already have
> > enabled in our builds, so I assume nothing actually needs this option.
> > If that's true, then it doesn't seem
Why not default to sha512 while still supporting sha1
On Wed, May 15, 2013 at 10:20 AM, Ard Biesheuvel
wrote:
> On 15 May 2013 07:03, Jonathan Aquilina wrote:
> > Not trying to hijack this thread, but I studied in my security class that
> > SHA1 is being attacked so to speak in terms of crypto
On 15 May 2013 07:03, Jonathan Aquilina wrote:
> Not trying to hijack this thread, but I studied in my security class that
> SHA1 is being attacked so to speak in terms of crypto analysis and it was
> suggested in the book that it not be used but something like SHA512 be used
> instead.
>
Hello J
On 14 May 2013 18:49, Jon Medhurst (Tixy) wrote:
>
> This also enables CONFIG_CRYPTO_SHA1 which we didn't already have
> enabled in our builds, so I assume nothing actually needs this option.
> If that's true, then it doesn't seem worth enabling an optimised version
> of code which isn't going to
On 13 May 2013 11:12, Nicolas Dechesne
> also in the link above all of the 7
> 'active' jobs are failing with 3 of them who always failed, and 2 of them
> failing for 2 weeks. so it's not clear what that means.
I we have a look at one og the jobs that is "always failing" :
https://ci.linaro.org/
20 matches
Mail list logo
