Re: [ANNOUNCE] linux-linaro kernel schedule for 13.05 published
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-tracking (llct) rebuild Thanks Andrey, we were looking forward to that. -Andy * Done: the tag is llct-20130515.1 * Changes: . the 3.8-based binder topic re-added . kernel/printk.c: build error in CONFIG_DEBUG_LL=y case fixed . "ARM: crypto: sha1-armv4-large.S: fix SP handling" patch needed to enable CONFIG_CRYPTO_SHA1_ARM The next step is: May 16: ll rebuild based on llct-20130515.1 The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date). Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule for 13.05 published
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 3.8-based binder topic re-added . kernel/printk.c: build error in CONFIG_DEBUG_LL=y case fixed . "ARM: crypto: sha1-armv4-large.S: fix SP handling" patch needed to enable CONFIG_CRYPTO_SHA1_ARM The next step is: May 16: ll rebuild based on llct-20130515.1 The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date). Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 worms, perhaps it's simpler if we just go with the linaro-base.conf patch which started this thread? :-) Yes please! I've just spotted that you have posted a fix to the ARM SHA1 code [1] so perhaps we shouldn't enable it until that fix works its way into the Linaro tree? (If it's important for Linaro work the perhaps you could ask Andrey to add the patch to the Linaro tree early.) - added the "ARM: crypto: sha1-armv4-large.S: fix SP handling" patch to linux-linaro-core-tracking tree starting from tag llct-20130515.1 Thanks, Andrey [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168374.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpuidle: arm_big_little: route target residency to mcpm
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 c-states. I suspect others may want to do the same. Do you know how suspend is done on tc2? Regarding guest kernels, I don't think I understand the implications. If we migrate between cores (having different parameters) in the middle of a cstate transition, can we have correct behavior? Wouldn't it be worse to migrate to a lower c-state then we had intended? Thanks, Sebastian On 15 May 2013 10:07, Jon Medhurst (Tixy) wrote: > 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 > > > > Generally, that's the Linaro kernel tree people should use and what is > built daily and released monthly. > > It's just it hasn't moved to 3.10 yet (will do in the next day or so) > but the topic branches which feed into it (that Liviu pointed out) have > already made that move. > > -- > Tixy > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpuidle: arm_big_little: route target residency to mcpm
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 > Generally, that's the Linaro kernel tree people should use and what is built daily and released monthly. It's just it hasn't moved to 3.10 yet (will do in the next day or so) but the topic branches which feed into it (that Liviu pointed out) have already made that move. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpuidle: arm_big_little: route target residency to mcpm
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 Lezcano wrote:
> 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 multiple powerdown cstates, the residency
> information
> >> indicates which powerdown state is targeted. Multiple powerdown cstate
> >> information can be maintained in the device tree and the vendor specific
> >> handling will then have enough information to determine what power
> state to
> >> enter without needing additional changes to the big_little framework.
> >>
> >> Signed-off-by: Sebastian Capella
> >> ---
> >> drivers/cpuidle/arm_big_little.c |6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/cpuidle/arm_big_little.c
> b/drivers/cpuidle/arm_big_little.c
> >> index a430800..8332b05 100644
> >> --- a/drivers/cpuidle/arm_big_little.c
> >> +++ b/drivers/cpuidle/arm_big_little.c
> >
> > I could not find a branch that contains this file. Which git tree and
> branch
> > are you using?
>
> I believe it should apply to:
>
>
> https://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=blob;f=drivers/cpuidle/arm_big_little.c;h=a430800d4a74c8c5b759cd34fb5e272d8cf8f8a3;hb=67b5adf6a402921655d337d52845d6d48c6ef2d2#l66
>
> >
> >> @@ -89,7 +89,7 @@ static int notrace bl_powerdown_finisher(unsigned
> long arg)
> >> unsigned int cpu = mpidr & 0xf;
> >>
> >> mcpm_set_entry_vector(cpu, cluster, cpu_resume);
> >> - mcpm_cpu_suspend(0); /* 0 should be replaced with better value
> here */
> >> + mcpm_cpu_suspend(arg);
> >> return 1;
> >> }
> >>
> >> @@ -107,6 +107,7 @@ static int bl_enter_powerdown(struct cpuidle_device
> *dev,
> >> {
> >> struct timespec ts_preidle, ts_postidle, ts_idle;
> >> int ret;
> >> + struct cpuidle_state *state = &drv->states[idx];
> >>
> >> /* Used to keep track of the total time in idle */
> >> getnstimeofday(&ts_preidle);
> >> @@ -117,7 +118,8 @@ static int bl_enter_powerdown(struct cpuidle_device
> *dev,
> >>
> >> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> >>
> >> - ret = cpu_suspend((unsigned long) dev, bl_powerdown_finisher);
> >> + ret = cpu_suspend((unsigned long) state->target_residency,
> >> + bl_powerdown_finisher);
> >
> > I don't think you should pass the target residency here but the intended
> > C-state. Think about what will happen when you run this in a guest
> kernel: is
> > the target_residency the same if the guest has been migrated from a big
> core
> > that might have a faster execution of the down/up path to a little core
> that
> > is slower? The intended C-state should stay the same, regardless of the
> actual
> > time it takes to get there and out, which affects the actual time spent
> inside
> > the state.
> >
> > Best regards,
> > Liviu
> >
>
>
> --
> Facebook |
> Twitter |
>
Re: [PATCH] cpuidle: arm_big_little: route target residency to mcpm
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 multiple powerdown cstates, the residency information
>> indicates which powerdown state is targeted. Multiple powerdown cstate
>> information can be maintained in the device tree and the vendor specific
>> handling will then have enough information to determine what power state to
>> enter without needing additional changes to the big_little framework.
>>
>> Signed-off-by: Sebastian Capella
>> ---
>> drivers/cpuidle/arm_big_little.c |6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpuidle/arm_big_little.c
>> b/drivers/cpuidle/arm_big_little.c
>> index a430800..8332b05 100644
>> --- a/drivers/cpuidle/arm_big_little.c
>> +++ b/drivers/cpuidle/arm_big_little.c
>
> I could not find a branch that contains this file. Which git tree and branch
> are you using?
I believe it should apply to:
https://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=blob;f=drivers/cpuidle/arm_big_little.c;h=a430800d4a74c8c5b759cd34fb5e272d8cf8f8a3;hb=67b5adf6a402921655d337d52845d6d48c6ef2d2#l66
>
>> @@ -89,7 +89,7 @@ static int notrace bl_powerdown_finisher(unsigned long arg)
>> unsigned int cpu = mpidr & 0xf;
>>
>> mcpm_set_entry_vector(cpu, cluster, cpu_resume);
>> - mcpm_cpu_suspend(0); /* 0 should be replaced with better value here */
>> + mcpm_cpu_suspend(arg);
>> return 1;
>> }
>>
>> @@ -107,6 +107,7 @@ static int bl_enter_powerdown(struct cpuidle_device *dev,
>> {
>> struct timespec ts_preidle, ts_postidle, ts_idle;
>> int ret;
>> + struct cpuidle_state *state = &drv->states[idx];
>>
>> /* Used to keep track of the total time in idle */
>> getnstimeofday(&ts_preidle);
>> @@ -117,7 +118,8 @@ static int bl_enter_powerdown(struct cpuidle_device *dev,
>>
>> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
>>
>> - ret = cpu_suspend((unsigned long) dev, bl_powerdown_finisher);
>> + ret = cpu_suspend((unsigned long) state->target_residency,
>> + bl_powerdown_finisher);
>
> I don't think you should pass the target residency here but the intended
> C-state. Think about what will happen when you run this in a guest kernel: is
> the target_residency the same if the guest has been migrated from a big core
> that might have a faster execution of the down/up path to a little core that
> is slower? The intended C-state should stay the same, regardless of the actual
> time it takes to get there and out, which affects the actual time spent inside
> the state.
>
> Best regards,
> Liviu
>
--
Facebook |
Twitter |
Re: [PATCH] cpuidle: arm_big_little: route target residency to mcpm
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
> indicates which powerdown state is targeted. Multiple powerdown cstate
> information can be maintained in the device tree and the vendor specific
> handling will then have enough information to determine what power state to
> enter without needing additional changes to the big_little framework.
>
> Signed-off-by: Sebastian Capella
> ---
> drivers/cpuidle/arm_big_little.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpuidle/arm_big_little.c
> b/drivers/cpuidle/arm_big_little.c
> index a430800..8332b05 100644
> --- a/drivers/cpuidle/arm_big_little.c
> +++ b/drivers/cpuidle/arm_big_little.c
I could not find a branch that contains this file. Which git tree and branch
are you using?
> @@ -89,7 +89,7 @@ static int notrace bl_powerdown_finisher(unsigned long arg)
> unsigned int cpu = mpidr & 0xf;
>
> mcpm_set_entry_vector(cpu, cluster, cpu_resume);
> - mcpm_cpu_suspend(0); /* 0 should be replaced with better value here */
> + mcpm_cpu_suspend(arg);
> return 1;
> }
>
> @@ -107,6 +107,7 @@ static int bl_enter_powerdown(struct cpuidle_device *dev,
> {
> struct timespec ts_preidle, ts_postidle, ts_idle;
> int ret;
> + struct cpuidle_state *state = &drv->states[idx];
>
> /* Used to keep track of the total time in idle */
> getnstimeofday(&ts_preidle);
> @@ -117,7 +118,8 @@ static int bl_enter_powerdown(struct cpuidle_device *dev,
>
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
>
> - ret = cpu_suspend((unsigned long) dev, bl_powerdown_finisher);
> + ret = cpu_suspend((unsigned long) state->target_residency,
> + bl_powerdown_finisher);
I don't think you should pass the target residency here but the intended
C-state. Think about what will happen when you run this in a guest kernel: is
the target_residency the same if the guest has been migrated from a big core
that might have a faster execution of the down/up path to a little core that
is slower? The intended C-state should stay the same, regardless of the actual
time it takes to get there and out, which affects the actual time spent inside
the state.
Best regards,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Do you use (review.)android.git.linaro.org?
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 between 2pm and 5pm, GMT+1, this Friday, 17th May. We are moving the server from Canonical to Amazon EC2. If you currently use review.android.git.linaro.org and sign in on it, please read the following information VERY CAREFULLY! At the moment, users are authenticated via OpenID with Launchpad. We are changing that to use OpenID with the Linaro Login service. If you don't know if you have a Linaro Login account, or you want to check that it is going to work properly: * Go to https://login.linaro.org:8443/openidserver. * If you are asked to log in, please enter your EMAIL ADDRESS and your Linaro Login password. If you don't know what your Linaro Login password is, or you cannot successfully log in, please contact me as soon as possible! * The web page should now display a URL of the format https://login.linaro.org:8443/openidserver/users/. This is your OpenID URL and means you will be ready to follow the link identity instructions below. After the maintenance has been completed, you will need to take the following steps ONCE: 1. Go to https://login.linaro.org:8443/openidserver. If you are asked to log in, please enter your EMAIL ADDRESS and your Linaro Login password. 2. The web page should now display a URL of the format https://login.linaro.org:8443/openidserver/users/. Make a note of that, please. 3. Go to http://review.android.git.linaro.org/. Sign in with your Launchpad ID. 4. When you have signed in, click on the Settings link in the top right corner of the web page. 5. Click on the Identities link on the left hand side of the web page. 6. Click on Link Another Identity. 7. Enter the URL you noted from step 2 and click on Link Identity. 8. If your web browser session from step 2 has expired, you will be asked to log in again - enter the same information you entered at step 1. 9. If your web browser session has not expired, or once you have logged in, you will see a web page with the title "OpenID Verification". On the right hand side, click on Allow Always. You should now be back at the Settings page. If you want to check that you can now sign in with your Linaro Login credentials, click on Sign Out in the corner of the Gerrit window, click Sign In and this time use the URL from step 2 rather than your Launchpad URL. You should be logged straight in if you have not closed any web browser windows. PLEASE NOTE: we will be supporting both Launchpad and Linaro Login OpenID authentication until the *end of May*. After that time, we will be switching over to just Linaro Login and you will no longer have to enter the OpenID URL - Gerrit will authenticate you directly with Linaro Login. Please do NOT attempt the above instructions until after the maintenance has been completed. I am providing the information now so that (a) you have it ready for use and (b) I can help anyone out if they do not know their Linaro Login details. If you have any questions, please email me. Thank you. Regards Philip Colmer IT Services Manager Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: automated build coverage
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 access to the detailed configuration of the jenkins jobs would be very useful. >>> >>> You've got access and can even view/modify the set up. >> >> I'm logged in to ci.linaro.org (via Launchpad) but I don't see the >> 'configure' option on any of the jobs, or the 'New Job' link to create >> a new job. What am I missing? > > Make sure "Team membership: linaro-ci-build-test-service" is checked > when you log in. Yup, that works. Now I can see all the configuration. Thanks. Kevin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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-base.conf patch which > > started this thread? :-) > > > > Yes please! Please make sure your sp adjustment patch is included or you'll get corrupted SHA1 digest whenever an interrupt is serviced in the middle of the SHA1 processing ( ... unless you have CONFIG_KPROBES=y in which case you would have been lucky to get headroom on the stack). Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 with the linaro-base.conf patch which > > started this thread? :-) > > > > Yes please! I've just spotted that you have posted a fix to the ARM SHA1 code [1] so perhaps we shouldn't enable it until that fix works its way into the Linaro tree? (If it's important for Linaro work the perhaps you could ask Andrey to add the patch to the Linaro tree early.) [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168374.html -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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? :-) > Yes please! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 is specifically target at ARMv4 > > means that on ARMv7 CPUs the latest GCC's might generate better code by > > using newer features? > > > > No, the v4 signifies that it supports v4 and up, but in fact the code > is tuned for dual issue, i.e. Cortex and up. > As far as I know, there is no reason not to use the asm versions if > you need the algos in the first place. 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? :-) -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 latest GCC's might generate better code by > using newer features? > No, the v4 signifies that it supports v4 and up, but in fact the code is tuned for dual issue, i.e. Cortex and up. As far as I know, there is no reason not to use the asm versions if you need the algos in the first place. -- Ard. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 worth enabling an optimised version > > of code which isn't going to be used. ;-) > > > > Good point. However, if I use merge_config to generate eg. > arndale/ubuntu, I end up with a .config which does have SHA1 and AES > enabled. I keep forgetting that some people still use ubuntu.conf, that enables the 2000+ config options used by Ubuntu for their desktop distro. We should really delete that and stick with ubuntu-minimal.conf (which I believe that Fathi was suggesting should become a generic linux disro config ) > So what would be the best way to enable CONFIG_CRYPTO_SHA1_ARM > automatically if some more specific config fragment enables > CONFIG_CRYPTO_SHA1 (and CONFIG_ARM), even if only through implicit > dependencies? I was going to suggest we had a patch which makes CONFIG_CRYPTO_SHA1_ARM default CONFIG_CRYPTO_SHA1 or something like that, but I see the dependency sort of goes the other way, because CRYPTO_SHA1_ARM selects CRYPTO_SHA1. 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 latest GCC's might generate better code by using newer features? Either way, it won't hurt to enable it in Linaro kernels as it doesn't look like it is ever used, so would just add to the kernel size a bit. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 analysis and it was > > suggested in the book that it not be used but something like SHA512 be > used > > instead. > > > > Hello Jonathan, > > Your professor is correct: SHA1 is not recommended for new development. > However, as it is very widely used, we will still need to support it > for a very long time. > > -- > Ard. > > > Just to give you all a heads up :) > > > > > > On Tue, May 14, 2013 at 6:49 PM, Jon Medhurst (Tixy) > > wrote: > >> > >> On Tue, 2013-05-14 at 14:16 +0200, Ard Biesheuvel wrote: > >> > These assembler implementations of SHA1 and AES have been > >> > in the upstream source tree since September 2012 but need > >> > to be selected explicitly in order to be enabled. > >> > > >> > Signed-off-by: Ard Biesheuvel > >> > --- > >> > linaro/configs/linaro-base.conf | 2 ++ > >> > 1 file changed, 2 insertions(+) > >> > > >> > diff --git a/linaro/configs/linaro-base.conf > >> > b/linaro/configs/linaro-base.conf > >> > index 5c748a7..ba7b97b 100644 > >> > --- a/linaro/configs/linaro-base.conf > >> > +++ b/linaro/configs/linaro-base.conf > >> > @@ -86,3 +86,5 @@ CONFIG_HW_PERF_EVENTS=y > >> > CONFIG_FUNCTION_TRACER=y > >> > CONFIG_ENABLE_DEFAULT_TRACERS=y > >> > CONFIG_PROC_DEVICETREE=y > >> > +CONFIG_CRYPTO_AES_ARM=y > >> > +CONFIG_CRYPTO_SHA1_ARM=y > >> > >> 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 be used. ;-) > >> > >> -- > >> Tixy > >> > >> > >> ___ > >> linaro-dev mailing list > >> linaro-dev@lists.linaro.org > >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > > > > > > > -- > > Jonathan Aquilina > -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 Jonathan, Your professor is correct: SHA1 is not recommended for new development. However, as it is very widely used, we will still need to support it for a very long time. -- Ard. > Just to give you all a heads up :) > > > On Tue, May 14, 2013 at 6:49 PM, Jon Medhurst (Tixy) > wrote: >> >> On Tue, 2013-05-14 at 14:16 +0200, Ard Biesheuvel wrote: >> > These assembler implementations of SHA1 and AES have been >> > in the upstream source tree since September 2012 but need >> > to be selected explicitly in order to be enabled. >> > >> > Signed-off-by: Ard Biesheuvel >> > --- >> > linaro/configs/linaro-base.conf | 2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > diff --git a/linaro/configs/linaro-base.conf >> > b/linaro/configs/linaro-base.conf >> > index 5c748a7..ba7b97b 100644 >> > --- a/linaro/configs/linaro-base.conf >> > +++ b/linaro/configs/linaro-base.conf >> > @@ -86,3 +86,5 @@ CONFIG_HW_PERF_EVENTS=y >> > CONFIG_FUNCTION_TRACER=y >> > CONFIG_ENABLE_DEFAULT_TRACERS=y >> > CONFIG_PROC_DEVICETREE=y >> > +CONFIG_CRYPTO_AES_ARM=y >> > +CONFIG_CRYPTO_SHA1_ARM=y >> >> 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 be used. ;-) >> >> -- >> Tixy >> >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > > -- > Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
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 be used. ;-) > Good point. However, if I use merge_config to generate eg. arndale/ubuntu, I end up with a .config which does have SHA1 and AES enabled. So what would be the best way to enable CONFIG_CRYPTO_SHA1_ARM automatically if some more specific config fragment enables CONFIG_CRYPTO_SHA1 (and CONFIG_ARM), even if only through implicit dependencies? -- Ard. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: automated build coverage
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/jenkins/job/linux-next/ We see that it is the snowball build, that has never built successfully, and thus jenkins considers the whole job failed. That is of course somewhat unfair representation, since other build are successful. But it also means, that nobody has cared about snowball in linux-next, not even enough to make the defconfig build. It is kind of underlining Russel's point - that CI is not useful if people are not watching the results and reacting on them. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
