Mr. Lassine Diawara | 18 Dec 11:13 2014
Picon

Greetings from Dr. Lassine Diawara.

-- 
Greetings from Dr. Lassine Diawara.

Assalamu Alaikum,

             Permit me to inform you of my desire of going into
business relationship with you, I know this message will sounds very
strange to you, but I have no choice than to risk my life to choose a
stranger like you I have never seen before. We leave in a global
world today, and with the help of internet technology one can easily
communicate with one  another all around the world without knowing him
or she in person, what matters will be  the trust and the
Information’s you got about the person. In this case we can understand
our self and work like one family.

My Name is Dr. Lassine Diawara, the senior Auditor In charge of
Foreign Remittance Unit, Bank of Africa (BOA). I'm from Ouagadougou,
Burkina Faso, West Africa. My reason for contacting you is to transfer
an abandoned $15.5M to your account.

The owner of this fund died since 2003 with his Next Of Kin. I want to
present you to the bank as the Next of Kin/beneficiary of this fund.

Further details of the transaction shall be forwarded to you as soon
as I receive your return mail indicating your interest.

I will like you to provide immediately the below information's, to
enable me use it and get you next of kin application form from my
bank.

(Continue reading)

Jarkko Sakkinen | 16 Dec 22:34 2014
Picon

Re: Re: [tpmdd-devel] [PATCH v10 0/8] TPM 2.0 support

On Tue, Dec 16, 2014 at 10:32:18PM +0100, Peter Huewe wrote:
> Hi,
> if I fix this (already adressed issue) 
>  #define TPM2_STARTUP_IN_SIZE \
>         (sizeof(struct tpm_input_header) + \
> -        sizeof(struct tpm2_pcr_read_in))
> +        sizeof(struct tpm2_startup_in))
>  
> it gets detected correctly.
>  
> I'll fix it, no updated patch needed.

Oops, I was too fast :)

> Not sure however if I think to reuse tpm2_startup_in also for shutdown, simply
> because it has  the same size, but ok.

They are equivalent messages except for the command code.

> Peter

/Jarkko
Young, David | 15 Dec 17:42 2014

selftests: standardized results output?

Hi,  I'm looking into what sorts of tools can consume the selftest output, and
found this on the wikipage:

https://kselftest.wiki.kernel.org/standardize_the_test_output

The current suggestion (as of the last-modified date on that wiki page for
October) is to use the Test Anything Protocol [TAP] for standard output.  I
notice that there is at least one test that conforms to TAP output, but
the majority of the tests are not using it.

There's also the kselftest.h file that suggests exit codes for the individual
test applications.

I'm interested in knowing what is the intention of this standardization, so
that I can put some work into a "glue" layer for a tool like buildbot,
autotest, or Jenkins for executing and consuming the results of these
selftests.

1) Is this output standard a "nice to have" that won't be much enforced?
2) Will the exit codes be utilized outside of the current makefile-based
   approach for executing the tests?  The current make target just runs all the
   tests without really concerning itself with the exit values of the
   individual tests.  It's simple, which isn't a bad thing, but it lacks a
   summarized result.  Is the intention to use a different harness to consume
   and report results?
3) Are the TAP results intended to be the exclusive (std)output of the tests,
   or will the tests report in a hybrid fashion?
   Such an example would be a test that produces some verbose stdout to the
   console, while simultaneously creating a TAP-compliant results.tap file as
   well... or vice versa with the stdout being TAP and a more verbose but
(Continue reading)

Jarkko Sakkinen | 12 Dec 20:46 2014
Picon

[PATCH v10 0/8] TPM 2.0 support

This patch set enables TPM2 protocol and provides drivers for FIFO and
CRB interfaces. This patch set does not export any sysfs attributes for
TPM 2.0 because existing sysfs attributes have three non-trivial issues:

- They are associated with the platform device instead of character
  device.
- They are are not trivial key-value pairs but contain text that is
  not easily parsed by a computer.
- Raciness as described in
  http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/

v2:
- Improved struct tpm_chip life-cycle by taking advantage of devres
  API.
- Refined sysfs attributes as simple key-values thereby not repeating
  mistakes in TPM1 sysfs attributes.
- Documented functions in tpm-chip.c and tpm2-cmd.c.
- Documented sysfs attributes.

v3:
- Lots of fixes in calling order in device drivers (thanks to Jason
  Gunthorpe for pointing these out!).
- Attach sysfs attributes to the misc device because it represents
  TPM device to the user space.

v4:
- Disable sysfs attibutes for TPM 2.0 for until we can sort out the 
  best approach for them.
- Fixed all the style issues found with checkpatch.pl.

(Continue reading)

Richard Guy Briggs | 9 Dec 21:37 2014
Picon

[PATCH V4] powerpc: add little endian flag to syscall_get_arch()

Since both ppc and ppc64 have LE variants which are now reported by uname, add
that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC64LE
variant.

Without this,  perf trace and auditctl fail.

Mainline kernel reports ppc64le (per a058801) but there is no matching
AUDIT_ARCH_PPC64LE.

Since 32-bit PPC LE is not supported by audit, don't advertise it in
AUDIT_ARCH_PPC* variants.

See:
	https://www.redhat.com/archives/linux-audit/2014-August/msg00082.html
	https://www.redhat.com/archives/linux-audit/2014-December/msg00004.html

Signed-off-by: Richard Guy Briggs <rgb@...>
---
 arch/powerpc/include/asm/syscall.h |    6 +++++-
 include/uapi/linux/audit.h         |    2 ++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index 6fa2708..d1934e5 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
 <at>  <at>  -90,6 +90,10  <at>  <at>  static inline void syscall_set_arguments(struct task_struct *task,

 static inline int syscall_get_arch(void)
 {
(Continue reading)

Lad, Prabhakar | 9 Dec 20:43 2014
Picon

[PATCH v6] media: platform: add VPFE capture driver support for AM437X

From: Benoit Parrot <bparrot-l0cyMroinI0 <at> public.gmane.org>

This patch adds Video Processing Front End (VPFE) driver for
AM437X family of devices
Driver supports the following:
- V4L2 API using MMAP buffer access based on videobuf2 api
- Asynchronous sensor/decoder sub device registration
- DT support

Signed-off-by: Benoit Parrot <bparrot-l0cyMroinI0 <at> public.gmane.org>
Signed-off-by: Darren Etheridge <detheridge-l0cyMroinI0 <at> public.gmane.org>
Signed-off-by: Lad, Prabhakar <prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
---
 Changes for v6:
 1: Fixed review comments pointed Hans, fixing race condition.
 
 v5: https://patchwork.kernel.org/patch/5459311/
 v4: https://patchwork.kernel.org/patch/5449211/
 v3: https://patchwork.kernel.org/patch/5434291/
 v2: https://patchwork.kernel.org/patch/5425631/
 v1: https://patchwork.kernel.org/patch/5362661/
 
 .../devicetree/bindings/media/ti-am437x-vpfe.txt   |   61 +
 MAINTAINERS                                        |    9 +
 drivers/media/platform/Kconfig                     |    1 +
 drivers/media/platform/Makefile                    |    2 +
 drivers/media/platform/am437x/Kconfig              |   11 +
 drivers/media/platform/am437x/Makefile             |    3 +
 drivers/media/platform/am437x/am437x-vpfe.c        | 2777 ++++++++++++++++++++
 drivers/media/platform/am437x/am437x-vpfe.h        |  283 ++
(Continue reading)

Young, David | 9 Dec 20:22 2014

selftests: question about git repos containing selftest.

Greetings,

I'm trying out the new kernel selftests and was looking for the "bleeding edge" repository to clone. 
According to the wiki https://kselftest.wiki.kernel.org/ this is the appropriate repo:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git

However, I am finding newer and more frequent changes are in linux-next.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Which should I clone for the most fresh changes?

-David Young
Li Xi | 9 Dec 06:22 2014
Picon

[v8 0/5] ext4: add project quota support

The following patches propose an implementation of project quota
support for ext4. A project is an aggregate of unrelated inodes
which might scatter in different directories. Inodes that belong
to the same project possess an identical identification i.e.
'project ID', just like every inode has its user/group
identification. The following patches add project quota as
supplement to the former uer/group quota types.

The semantics of ext4 project quota is consistent with XFS. Each
directory can have EXT4_INODE_PROJINHERIT flag set. When the
EXT4_INODE_PROJINHERIT flag of a parent directory is not set, a
newly created inode under that directory will have a default project
ID (i.e. 0). And its EXT4_INODE_PROJINHERIT flag is not set either.
When this flag is set on a directory, following rules will be kept:

1) The newly created inode under that directory will inherit both
the EXT4_INODE_PROJINHERIT flag and the project ID from its parent
directory.

2) Hard-linking a inode with different project ID into that directory
will fail with errno EXDEV.

3) Renaming a inode with different project ID into that directory
will fail with errno EXDEV. However, 'mv' command will detect this
failure and copy the renamed inode to a new inode in the directory.
Thus, this new inode will inherit both the project ID and
EXT4_INODE_PROJINHERIT flag.

4) If the project quota of that ID is being enforced, statfs() on
that directory will take the quotas as another upper limits along
(Continue reading)

Lad, Prabhakar | 8 Dec 23:21 2014
Picon

[PATCH v5] media: platform: add VPFE capture driver support for AM437X

From: Benoit Parrot <bparrot-l0cyMroinI0 <at> public.gmane.org>

This patch adds Video Processing Front End (VPFE) driver for
AM437X family of devices
Driver supports the following:
- V4L2 API using MMAP buffer access based on videobuf2 api
- Asynchronous sensor/decoder sub device registration
- DT support

Signed-off-by: Benoit Parrot <bparrot-l0cyMroinI0 <at> public.gmane.org>
Signed-off-by: Darren Etheridge <detheridge-l0cyMroinI0 <at> public.gmane.org>
Signed-off-by: Lad, Prabhakar <prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
---
 Changes for v5:
 1: Fixed review comments pointed out by Hans, fixing race condition.

 v4l2-compliance output:-
 ----------------------

 root <at> am437x-evm:~# ./v4l2-compliance -s -i 0 -vv
Driver Info:
        Driver name   : vpfe
        Card type     :[  262.490769] vpfe 48328000.vpfe: =================  START STATUS  =================
 TI AM437x VPFE
        Bus info      : platform:vpfe [  262.502285] vpfe 48328000.vpfe: ==================  END STATUS  ==================
48328000.vpfe
        Driver version: 3.18.0
        Capabil[  262.515396] vpfe 48328000.vpfe: invalid input index: 1
ities  : 0x85200001
                Video Capture
(Continue reading)

Richard Guy Briggs | 8 Dec 18:59 2014
Picon

[PATCH V3] powerpc: add little endian flag to syscall_get_arch()

Since both ppc and ppc64 have LE variants which are now reported by uname, add
that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC*LE
variants.

Without this,  perf trace and auditctl fail.

Mainline kernel reports ppc64le (per a058801) but there is no matching
AUDIT_ARCH_PPC64LE.

Since 32-bit PPC LE is not supported, throw a compiler error rather than return
a bogus architecture to audit.

See:
	https://www.redhat.com/archives/linux-audit/2014-August/msg00082.html
	https://www.redhat.com/archives/linux-audit/2014-December/msg00004.html

v2 -> v3:
	Throw a compiler error on 32-bit LE.

v1 -> v2:
	Added ";" at the end of the #ifdef-protected line so it actually compiles

Signed-off-by: Richard Guy Briggs <rgb@...>
---
 arch/powerpc/include/asm/syscall.h |    7 +++++++
 include/uapi/linux/audit.h         |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index 6fa2708..cf7fcab 100644
(Continue reading)

Richard Guy Briggs | 8 Dec 18:58 2014
Picon

[PATCH V2] powerpc: add little endian flag to syscall_get_arch()

Since both ppc and ppc64 have LE variants which are now reported by uname, add
that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC*LE
variants.

Without this,  perf trace and auditctl fail.

Mainline kernel reports ppc64le (per a058801) but there is no matching
AUDIT_ARCH_PPC64LE.

See:
	https://www.redhat.com/archives/linux-audit/2014-August/msg00082.html
	https://www.redhat.com/archives/linux-audit/2014-December/msg00004.html

v1 -> v2:
	Added ";" at the end of the #ifdef-protected line so it actually compiles

Signed-off-by: Richard Guy Briggs <rgb@...>
---
 arch/powerpc/include/asm/syscall.h |    6 +++++-
 include/uapi/linux/audit.h         |    2 ++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index 6fa2708..d1934e5 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
 <at>  <at>  -90,6 +90,10  <at>  <at>  static inline void syscall_set_arguments(struct task_struct *task,

 static inline int syscall_get_arch(void)
 {
(Continue reading)


Gmane