Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

2013-02-21 Thread Phil Carmody
Apologies if this is misthreaded, I had to hand-craft the headers.

> The patch offers an entropy generator based on CPU timing jitter. The 
> entropy collector has the following properties:
> 
> * it does not maintain any state and therefore does not need any seed

What is this "pool" if it's not "state"?

> /* Entropy pool of the RNG which is filled upon each request for entropy */
> struct rand_data

And, from looking at jitterentropy_entropy_calc(), it seems to think that
the [source producing the] following sequence of timestamps:

1000, 1010, 1030, 1050, 1060, 1080, 1090, 1110, 1120, ...
i.e. with absolutely metronomic deltas of 10, 20, 10, 20, 10, 20, ...

has 4 bit of entropy per reading. I hope I don't have to explicitly say
that it clearly it has 0 bits of entropy.

Entropy harvesting is quite hard - entropy estimation is unimaginably harder.
Phil
-- 
"In a world of magnets and miracles" 
-- Insane Clown Posse, Miracles, 2009. Much derided.
"Magnets, how do they work"
-- Pink Floyd, High Hopes, 1994. Lauded as lyrical geniuses.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] smack: fix magic value

2013-07-10 Thread Phil Carmody
5d is ']', 'M' is 4d.

Signed-off-by: Phil Carmody 
---
 include/uapi/linux/magic.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
index 2944278..5c1d878 100644
--- a/include/uapi/linux/magic.h
+++ b/include/uapi/linux/magic.h
@@ -11,7 +11,7 @@
 #define DEBUGFS_MAGIC  0x64626720
 #define SECURITYFS_MAGIC   0x73636673
 #define SELINUX_MAGIC  0xf97cff8c
-#define SMACK_MAGIC0x43415d53  /* "SMAC" */
+#define SMACK_MAGIC0x43414d53  /* "SMAC" */
 #define RAMFS_MAGIC0x858458f6  /* some random number */
 #define TMPFS_MAGIC0x01021994
 #define HUGETLBFS_MAGIC0x958458f6  /* some random number */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V4 02/15] asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa

2013-09-23 Thread Phil Carmody
On Sun, Sep 15, 2013 at 08:56:48AM +0800, Lee, Chun-Yi wrote:
> Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
> first step of signature generation operation (RSASSA-PKCS1-v1_5-SIGN).
> 
> This patch is temporary set emLen to pks->k, and temporary set EM to
> pks->S for debugging. We will replace the above values to real signature
> after implement RSASP1.
> 
> The naming of EMSA_PKCS1_v1_5_ENCODE and the variables used in this function
> accord PKCS#1 spec but not follow kernel naming convention, it useful when 
> look
> at them with spec.
> 
> Reference: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1v2/pkcs1ietffinal.txt
> Reference: 
> http://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf
> 
> V2:

You're now at V4.

> - Clean up naming of variable: replace _EM by EM, replace EM by EM_tmp.
> - Add comment to EMSA_PKCS1-v1_5-ENCODE function.
> 
> Cc: Pavel Machek 
> Reviewed-by: Jiri Kosina 
> Signed-off-by: Lee, Chun-Yi 
> ---
>  crypto/asymmetric_keys/rsa.c |  163 
> +-
>  include/crypto/public_key.h  |2 +
>  2 files changed, 164 insertions(+), 1 deletions(-)
> 
> diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
> index 47f3be4..352ba45 100644
> --- a/crypto/asymmetric_keys/rsa.c
> +++ b/crypto/asymmetric_keys/rsa.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "public_key.h"
>  #include "private_key.h"
>  
> @@ -152,6 +153,132 @@ static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
>  }
>  
>  /*
> + * EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2]
> + * @M: message to be signed, an octet string
> + * @emLen: intended length in octets of the encoded message
> + * @hash_algo: hash function (option)
> + * @hash: true means hash M, otherwise M is already a digest
> + * @EM: encoded message, an octet string of length emLen
> + *
> + * This function is a implementation of the EMSA-PKCS1-v1_5 encoding 
> operation
> + * in RSA PKCS#1 spec. It used by the signautre generation operation of
> + * RSASSA-PKCS1-v1_5 to encode message M to encoded message EM.
> + *
> + * The variables used in this function accord PKCS#1 spec but not follow 
> kernel
> + * naming convention, it useful when look at them with spec.
> + */
> +static int EMSA_PKCS1_v1_5_ENCODE(const u8 *M, size_t emLen,
> + enum pkey_hash_algo hash_algo, const bool hash,
> + u8 **EM, struct public_key_signature *pks)
> +{
> + u8 *digest;
> + struct crypto_shash *tfm;
> + struct shash_desc *desc;
> + size_t digest_size, desc_size;
> + size_t tLen;
> + u8 *T, *PS, *EM_tmp;
> + int i, ret;
> +
> + pr_info("EMSA_PKCS1_v1_5_ENCODE start\n");
> +
> + if (!RSA_ASN1_templates[hash_algo].data)
> + ret = -ENOTSUPP;

...

> + else
> + pks->pkey_hash_algo = hash_algo;
> +
> + /* 1) Apply the hash function to the message M to produce a hash value 
> H */
> + tfm = crypto_alloc_shash(pkey_hash_algo[hash_algo], 0, 0);
> + if (IS_ERR(tfm))
> + return (PTR_ERR(tfm) == -ENOENT) ? -ENOPKG : PTR_ERR(tfm);
> +
> + desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
> + digest_size = crypto_shash_digestsize(tfm);
> +
> + ret = -ENOMEM;

The earlier "ret = -ENOTSUPP;" is either unused because you return at the 
IS_ERR,
or unused because you overwrite it here. I'm a little disappointed that
the compiler didn't recognise that something was assigned to a value that 
is never used.

Phil

> +
> + digest = kzalloc(digest_size + desc_size, GFP_KERNEL);
> + if (!digest)
> + goto error_digest;
> + pks->digest = digest;
> + pks->digest_size = digest_size;
> +
> + if (hash) {
> + desc = (void *) digest + digest_size;
> + desc->tfm = tfm;
> + desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
> +
> + ret = crypto_shash_init(desc);
> + if (ret < 0)
> + goto error_shash;
> + ret = crypto_shash_finup(desc, M, sizeof(M), pks->digest);
> + if (ret < 0)
> + goto error_shash;
> + } else {
> + memcpy(pks->digest, M, pks->digest_size);
> + pks->digest_size = digest_size;
> + }
> + crypto_free_shash(tfm);
> +
> + /* 2) Encode the algorithm ID for the hash function and the hash value 
> into
> +  * an ASN.1 value of type DigestInfo with the DER. Let T be the DER 
> encoding of
> +  * the DigestInfo value and let tLen be the length in octets of T.
> +  */
> + tLen = RSA_ASN1_templates[hash_algo].size + pks->digest_size;
> + T = kmalloc(tLen, GFP_KERNEL);
> + if (!T)
> + goto error_T;
> +
> + memcpy(T, RSA_ASN1_templates[hash_algo].data, 
> RSA_ASN1_templates[hash_algo].size);
> + memcpy(T + RSA_ASN1_templates[hash_algo].size, pks->digest, 
> pks->digest_size);
> +
> + /* 3) check If emLen <

RE: [PATCH] checkpatch: forgive use of mixed case variables measuring units

2013-06-12 Thread Phil Carmody
Joe Perches wrote:
> On Wed, 2013-05-29 at 14:02 +0300, Phil Carmody wrote:
> > I don't think anyone really has an issue with things like max_mV.
> > And whilst nS et al. may not be SI standard, at least it's clear
> > what they represent.
> []
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -2940,6 +2940,7 @@ sub process {
> > if ($var !~ /$Constant/ &&
> > $var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
> > $var !~
/"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
> > +   $var !~ /^[a-z_]*_[numk][VAS]$/ &&
> > !defined $camelcase{$var}) {
> > $camelcase{$var} = 1;
> > WARN("CAMELCASE",
> 
> Hi Phil.
> 
> CamelCase was downgraded to a --strict only (CHK)
> test in -next recently.  commit f0e8102413
> ("checkpatch: change CamelCase test and make it --strict")
> 
> I'm hesitant to add a longish whitelist inside
> checkpatch itself, but if it's added, it should
> probably be an array.

Thanks for the response, Joe, sorry I didn't reply earlier.

I agree that a creeping list of exceptions where CamelCase
is to be overlooked would be bad, but I would argue that 
perhaps my exceptions aren't actual CamelCase - they're
(pretending to be) SI units, and just happen to match the
CamelCase regexp. I did a grep for my regexp, and everything
I noticed in a quick scan did look like a justifiable 
variable name.

Of course, it's not a biggie either way, and of course it's
your call, but I do feel my patch has enough merit to be
worth defending.

Cheers,
Phil



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-20 Thread Phil Carmody
(Apologies if this is mangled, fighting both Outlook and remote desktop :-(
)

linux-kernel-ow...@vger.kernel.org wrote on Behalf Of Mark Brown
> On Wed, Jun 19, 2013 at 08:26:12PM +0200, Tomasz Figa wrote:
> > On Wednesday 19 of June 2013 18:40:47 Mark Brown wrote:
> 
> > > - ret = pd->get_signal(plchan->cd);
> > > + ret = (pd->get_signal)(plchan->cd);
> 
> > Hmm, that's strange. The former is a completely valid piece of
> code...
> 
> I know, hence...
> 
> > > to get it to build which makes me suspect the compiler a bit as
> well...
> 
> ...my comment about suspecting the compiler.

Can you just make that minimal change, and diff the objdump of the two .o's?
It would be worth a bug-report against the toolchain if different code was
being generated. If objdump spews huge numbers of diffs (due to one address
changing and pushing everything else out of kilter), then feel free to
forward both .o's or both objdumps to me, and I can run a script over them,
which knows to ignore unimportant address changes. 

Praying that this mail is readable to you, as it's not readable as I write
it,
Phil


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA

2013-06-20 Thread Phil Carmody
> -Original Message-
> On Thu, Jun 20, 2013 at 12:24:47PM +0300, Phil Carmody wrote:
> > Can you just make that minimal change, and diff the objdump of the
> two .o's?
> > It would be worth a bug-report against the toolchain if different
> code
> > was being generated. If objdump spews huge numbers of diffs (due to
> > one address changing and pushing everything else out of kilter), then
> > feel free to forward both .o's or both objdumps to me, and I can run
> a
> > script over them, which knows to ignore unimportant address changes.
> 
> See Arnd's followup - this looks like a collision with the get_signal
> macro in signal.h.


With my language-lawyer hat on, I'd suggest ``(get_signal)'' to prevent the
macro expansion:

/tmp$ cat crap.c

#define fnlikemacro(foo) foo+

int x(int y) {
  int (fnlikemacro) = y;
  return fnlikemacro(y)(fnlikemacro);
}

/tmp$ gcc -E crap.c

int x(int y) {
  int (fnlikemacro) = y;
  return y+(fnlikemacro);
}

(and yes, that compiles.)

However, it's more tempting (i.e. sensible) to just rename the 
one with the weaker claim to the name.

Phil


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] checkpatch: forgive use of mixed case variables measuring units

2013-05-29 Thread Phil Carmody
I don't think anyone really has an issue with things like max_mV.
And whilst nS et al. may not be SI standard, at least it's clear
what they represent.

Signed-off-by: Phil Carmody 
---
 scripts/checkpatch.pl |1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b954de5..c29fd2f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2940,6 +2940,7 @@ sub process {
if ($var !~ /$Constant/ &&
$var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
$var !~ 
/"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
+   $var !~ /^[a-z_]*_[numk][VAS]$/ &&
!defined $camelcase{$var}) {
$camelcase{$var} = 1;
WARN("CAMELCASE",
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 1/1] checkpatch: fix some whitespace issues caused by --fix

2013-08-05 Thread Phil Carmody
Lines with incorrect spacing around an operator, such as:
  bystander, correct,incorrect
would get "fixed" to
  bystander,correct, incorrect
as the correct argument as well as the incorrectly-spaced operator
were both being trimmed. The correct argument only needs to be
right trimmed.

Signed-off-by: Phil Carmody 
---
 scripts/checkpatch.pl |   19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 2ee9eb7..b5f4157 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1432,6 +1432,13 @@ sub check_absolute_file {
}
 }
 
+sub rtrim {
+   my ($string) = @_;
+
+   $string =~ s/\s+$//;
+
+   return $string;
+}
 sub trim {
my ($string) = @_;
 
@@ -2852,7 +2859,7 @@ sub process {
if ($ctx !~ /.x[WEC]/ && $cc !~ /^}/) {
if (ERROR("SPACING",
  "space required after 
that '$op' $at\n" . $hereptr)) {
-   $good = 
trim($fix_elements[$n]) . trim($fix_elements[$n + 1]) . " ";
+   $good = 
rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]) . " ";
$line_fixed = 1;
}
}
@@ -2881,7 +2888,7 @@ sub process {
if (ERROR("SPACING",
  "space prohibited 
after that '$op' $at\n" . $hereptr)) {
$fixed_line =~ s/\s+$//;
-   $good = 
trim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
+   $good = 
rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
$line_fixed = 1;
if (defined 
$fix_elements[$n + 2]) {

$fix_elements[$n + 2] =~ s/^\s+//;
@@ -2904,7 +2911,7 @@ sub process {
if (ERROR("SPACING",
  "space prohibited 
before that '$op' $at\n" . $hereptr)) {
$fixed_line =~ s/\s+$//;
-   $good = 
trim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
+   $good = 
rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
$line_fixed = 1;
}
}
@@ -2912,7 +2919,7 @@ sub process {
if (ERROR("SPACING",
  "space prohibited 
after that '$op' $at\n" . $hereptr)) {
$fixed_line =~ s/\s+$//;
-   $good = 
trim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
+   $good = 
rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
$line_fixed = 1;
if (defined 
$fix_elements[$n + 2]) {

$fix_elements[$n + 2] =~ s/^\s+//;
@@ -2931,7 +2938,7 @@ sub process {
if (ERROR("SPACING",
  "need consistent 
spacing around '$op' $at\n" . $hereptr)) {
$fixed_line =~ s/\s+$//;
-   $good = 
trim($fix_elements[$n]) . " " . trim($fix_elements[$n + 1]) . " ";
+   $good = 
rtrim($fix_elements[$n]) . " " . trim($fix_elements[$n + 1]) . " ";
$line_fixed = 1;
}
}
@@ -2942,7 +2949,7 @@ sub process {
if ($ctx =~ /Wx./) {
if (ERROR("SPACING&qu

RE: [PATCH 1/1] checkpatch: fix some whitespace issues caused by --fix

2013-08-06 Thread Phil Carmody
> On Mon, 2013-08-05 at 14:08 +0300, Phil Carmody wrote:
> > Lines with incorrect spacing around an operator, such as:
> >   bystander, correct,incorrect
> > would get "fixed" to
> >   bystander,correct, incorrect
> > as the correct argument as well as the incorrectly-spaced operator
> > were both being trimmed. The correct argument only needs to be right
> > trimmed.
> 
> Thanks for the patch, but I think it needs a different fix.

I think it's the right approach, but you're right, it doesn't
fix all the problems. However, in part that's because many 
copies of the string, or bits of it, are created, and when 
one copy is modified, the others don't replicate that change.

> Even after your patch the --fix option still makes a mess of several
> code spacing issues.

Indeed. Just seen - func(foo,&bar); becoming func(foo,  &bar);, 
as --fix wants to put a space both after the ',' and before the '&'.

> I'll work on it and propose something soonish.

It's very much a WIP - I'll send my bride-of-checkpatch to you 
as soon as I've written some blurb. It might be that the 
complexities inside checkpatch can't be overcome, and it's
easier to address the changes entirely in a separate script?

Phil


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[[RFC]] scripts/robopatch.pl: the mechanical bride of checkpatch.pl

2013-08-06 Thread Phil Carmody
Checkpatch knows a lot about the linux coding style. It's very
helpful in telling us humans what to change in order to improve
our C code. However, as lazy humans, we rarely do that.

That's where robopatch steps in - it will take the output
of checkpatch, and attempt to perform all the changes that
it feels confident it can do without breaking the code.

Think of it like a 'roid-raged indent/Lindent or cleanfile.

Yes, that's like them on steroids, and with all the mindlessness
that implies. It really doesn't attempt to understand much C at
all, it relies on checkpatch knowing about those kinds of things,
and then just blindly obeys orders. ALWAYS CHECK ITS CHANGES.

Signed-off-by: Phil Carmody 
---
 scripts/robopatch.pl |  465 ++
 1 file changed, 465 insertions(+)
 create mode 100755 scripts/robopatch.pl

diff --git a/scripts/robopatch.pl b/scripts/robopatch.pl
new file mode 100755
index 000..784f355
--- /dev/null
+++ b/scripts/robopatch.pl
@@ -0,0 +1,465 @@
+#!/usr/bin/perl -w
+#
+# robopatch.pl
+#
+# Author: Phil Carmody 
+# Copyright 2013- Samsung Electronics Ltd.
+# Licensed under the terms of the GNU GPL License version 2
+
+# Attempt to clean files mentioned in checkpatch output.
+# It relies on checkpatch having all the intelligence,
+# isolating the problems very specifically, so the actual
+# fixes can be done relatively safely. However, you should
+# always check the output.
+
+# Error handling is on a fail-early and fail-often policy.
+# Verbose logging goes to stderr presently, while this is WIP.
+
+# Typical usage:
+# $ scripts/checkpatch.pl WHATEVER > /tmpcheckpatch.log
+# $ scripts/robopatch.pl < /tmp/checkpatch.log
+# $ git diff
+#
+
+use strict qw(refs subs vars);
+use warnings;
+
+# This script edits files in place unless --dryrun is set
+my $dryrun=0;
+
+# TODO: permit filtering of which rules you want to act upon.
+my $filtered=0;
+
+while(@ARGV and $ARGV[0] =~ m/^-/) {
+my $arg=shift(@ARGV);
+if($arg =~ m/--dryrun/) {
+   $dryrun=1;
+}
+if($arg =~ m/--filter=(.+)/) {
+   # TODO: parse a filter file
+   $filtered=1;
+}
+if($arg =~ m/--/) { last; }
+}
+
+my %aliases;# short name -> full path
+my %files;  # short name -> array of changes
+my @files;  # short name in order seen
+
+my $lastfile=undef;
+my $lastline=undef;
+my $state=0;
+my $build=undef;
+while(<>) {
+chomp;
+my $handled=0;
+if($state==0
+   and m/^total: (\d+) errors, (\d+) warnings, (\d+) lines checked/) {
+   if(defined($lastfile)) {
+   print STDERR "$lastfile: E/W/L=$1/$2/$3\n" if($1 or $2 or $3);
+   $state=4;
+   } else {
+   $state=5;
+   }
+   $handled=1;
+} elsif($state==0 and m/^(?:WARNING|ERROR): .*/) {
+   die("unknown state before: $_") if($build);
+   $build={ message => $_ };
+   $state=1;
+   $handled=1;
+} elsif($state==0 and 
+   m/^(If any of these errors are false|them to the maintainer)/) {
+   $handled=1;
+} elsif($state==1 and m/^#\d+: FILE: (.+):(\d+):$/) {
+   my ($f, $l)=($1, $2);
+   die("file confusion, lf=$lastfile f=$f") if(defined($lastfile) and 
$lastfile ne $f);
+   if(!defined($files{$f})) { push @files, $f; $files{$f}=[]; }
+   if(defined($lastfile) and defined($lastline) and ($lastline eq $l)
+  and ($files{$lastfile}->[-1]->{'message'} eq $build->{'message'})) {
+   # This message is identical to the previous one, just tally.
+   $build->{'tally'}=$files{$lastfile}->[-1]->{'tally'}+1;
+   pop(@{$files{$lastfile}});
+   } else {
+   $build->{'tally'}=1;
+   }
+   $build->{'file'}=$f;
+   $build->{'line'}=$l;
+   $build->{'fileline'}=$_;
+   $build->{'lines'}=[];
+   $lastfile=$f;
+   $lastline=$l;
+   $state=2;
+   $handled=1;
+} elsif($state==2 and m/^(\+|\[\.\.\.\]$)/) {
+   push @{$build->{'lines'}}, $_;
+   $handled=1;
+} elsif($state==2 and m/^ (\s*)\^/) {
+   if(@{$build->{'lines'}} != 1 or defined($build->{'column'})) {
+   die("column confusion") 
+   }
+   $build->{'column'}=$_;
+   $handled=1;
+} elsif(($state==2 or $state==3) and m/^$/) {
+   push @{$files{$lastfile}}, $build;
+   $build=undef;
+   $state=0;
+   $handled=1;
+} elsif($state==4 and m/^(.+) has style problems, please review/) {
+   $aliases{$lastfile}=$1;
+   $lastfile=undef;
+   $lastline=undef;
+   $state=0;
+   $handled=1;
+} elsif($state==4 or $state==5 or $state==0 and m/^$/) {
+   $handled=1;
+} else {
+   die("in state $state (lf=$lastfile), what's: 

Re: [patch v7 05/21] sched: log the cpu utilization at rq

2013-05-06 Thread Phil Carmody
[Apologies if threading mangled, all headers written by hand]

On 04/04/2013 07:30 AM, Alex Shi wrote:
> The cpu's utilization is to measure how busy is the cpu.
> util = cpu_rq(cpu)->avg.runnable_avg_sum * SCHED_POEWR_SCALE
> / cpu_rq(cpu)->avg.runnable_avg_period;
> 
> Since the util is no more than 1, we scale its value with 1024, same as
> SCHED_POWER_SCALE and set the FULL_UTIL as 1024.
> 
> In later power aware scheduling, we are sensitive for how busy of the
> cpu. Since as to power consuming, it is tight related with cpu busy
> time.
> 
> BTW, rq->util can be used for any purposes if needed, not only power
> scheduling.
> 
> Signed-off-by: Alex Shi 
> ---
>  include/linux/sched.h | 2 +-
>  kernel/sched/debug.c  | 1 +
>  kernel/sched/fair.c   | 5 +
>  kernel/sched/sched.h  | 4 
>  4 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5a4cf37..226a515 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -793,7 +793,7 @@ enum cpu_idle_type {
>  #define SCHED_LOAD_SCALE (1L << SCHED_LOAD_SHIFT)
> 
>  /*
> - * Increase resolution of cpu_power calculations
> + * Increase resolution of cpu_power and rq->util calculations
>   */
>  #define SCHED_POWER_SHIFT10
>  #define SCHED_POWER_SCALE(1L << SCHED_POWER_SHIFT)
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index 75024a6..f5db759 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -311,6 +311,7 @@ do {  
> \
> 
>   P(ttwu_count);
>   P(ttwu_local);
> + P(util);
> 
>  #undef P
>  #undef P64
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2e49c3f..7124244 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1495,8 +1495,13 @@ static void update_cfs_rq_blocked_load(struct cfs_rq 
> *cfs_rq, int force_update)
> 
>  static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
>  {
> + u32 period;
>   __update_entity_runnable_avg(rq->clock_task, &rq->avg, runnable);
>   __update_tg_runnable_avg(&rq->avg, &rq->cfs);
> +
> + period = rq->avg.runnable_avg_period ? rq->avg.runnable_avg_period : 1;
> + rq->util = (u64)(rq->avg.runnable_avg_sum << SCHED_POWER_SHIFT)
> + / period;

Greetings, Alex.

That cast achieves nothing where it is. If the shift has overflowed,
then you've already lost information; and if it can't overflow, then
it's not needed at all. 

It's itsy-bitsy, but note that there exists a div_u64(u64 dividend,
u32 divisor) helper which may be implemented to be superior to just '/'.
(And also note that the assignment to ``period'' is a good candidate for
gcc's ``?:'' operator.)

If you pull the cast inside the brackets, then you may add my
Reviewed-by: Phil Carmody 

Cheers,
Phil

>  }
> 
>  /* Add the load generated by se into cfs_rq's child load-average */
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 804ee41..8682110 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -351,6 +351,9 @@ extern struct root_domain def_root_domain;
> 
>  #endif /* CONFIG_SMP */
> 
> +/* full cpu utilization */
> +#define FULL_UTILSCHED_POWER_SCALE
> +
>  /*
>   * This is the main, per-CPU runqueue data structure.
>   *
> @@ -482,6 +485,7 @@ struct rq {
>  #endif
> 
>   struct sched_avg avg;
> + unsigned int util;
>  };
> 
>  static inline int cpu_of(struct rq *rq)
> 
-- 
"In a world of magnets and miracles" 
-- Insane Clown Posse, Miracles, 2009. Much derided.
"Magnets, how do they work"
-- Pink Floyd, High Hopes, 1994. Lauded as lyrical geniuses.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] Makefile: make sparse (CHECK) user-selectable

2013-05-08 Thread Phil Carmody
I've got a tweaked version as well as the system default,
so make the sparse binary that's run user-selectable.

Signed-off-by: Phil Carmody 
---
 Makefile |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index a3a834b..e7a4851 100644
--- a/Makefile
+++ b/Makefile
@@ -338,7 +338,9 @@ GENKSYMS= scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
 DEPMOD = /sbin/depmod
 PERL   = perl
-CHECK  = sparse
+ifndef CHECK
+  CHECK= sparse
+endif
 
 CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
  -Wbitwise -Wno-return-void $(CF)
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Makefile: make sparse (CHECK) user-selectable

2013-05-09 Thread Phil Carmody
On 08/05/13 10:44 -0700, Randy Dunlap wrote:
> On 05/08/13 08:23, Phil Carmody wrote:
> > I've got a tweaked version as well as the system default,
> > so make the sparse binary that's run user-selectable.
> > 
> 
> I'm confused about why this patch is necessary since I already do
> 
> $ make O=builddir CHECK=/path/to/sparse all

Ach, OK. I was presuming that I should be able to select my sparse
in the same way that I select my cross compiler, namely in the ENV.

CROSS_COMPILE=whatever- CHECK=/my/sparse make C=1

Doctor - it hurts when I do >this<, ouch.
Well, don't do that then!

Phil
-- 
"In a world of magnets and miracles" 
-- Insane Clown Posse, Miracles, 2009. Much derided.
"Magnets, how do they work"
-- Pink Floyd, High Hopes, 1994. Lauded as lyrical geniuses.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Disabling the tsc2005 driver at runtime

2013-10-11 Thread Phil Carmody
Greetings, Dmitry,

I'm looking for some advice regarding locally restoring a feature into
the tsc2005 driver that was removed back in:
  http://www.spinics.net/lists/linux-input/msg14575.html
  commit 5cb81d1: Input: tsc2005 - remove 'disable' sysfs attribute

Given the prior patch in the patchset:
  commit 0b950d3: Input: tsc2005 - add open/close
  "Introduce open and close methods for the input device 
   to keep the device powered down when it is not in use."
it seems you were expecting the device node to only have one reader, and
that reader would be the entity who decided when it was time to disable
and power down the device.

However, in the Nokia N900, the device node has at least 3 readers, 2 of
which I believe are closed source components, and therefore cannot be
modified to follow kernel changes. And even then, forcing 3 userspace
programs to now have to actively participate in the disabling of the
device seems excessively wasteful, compared with the ultimate simplicity
of the clients not even having to know about such things, which is how
it was before the change.

Back then you mentioned a generic interface that should replace this
device-specific one, but I can see no documentation for such an
interface in the kernel Documentation/ABI. Can you elaborate?

At the moment, as we can't break userspace, it seems that if we want to
run a more modern kernel on the N900 or another tsc2005-based device
running Fremantle, we should just locally revert that patch, and take 
the maintenance hit ourselves for the implications of that. (Here 'we'
= the volunteer community still supporting the device because of its
longevity.)

Cheers,
Phil
-- 
People generally seem to want software to be free as in speech and/or
free as in beer. Unfortunately rather too much of it is free as in jazz.
-- Janet McKnight, on a private newsgroup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/