linux-toradex.git/Documentation, branch v3.4.89

hwmon: (coretemp) Add support for Atom CE4110/4150/4170

2014-04-14T13:44:31+00:00

commit 1102dcab849313bd5a340b299b5cf61b518fbc0f upstream.

TjMax for the CE4100 series of Atom CPUs was previously reported to be
110 degrees C.

cpuinfo logs on the web show existing CPU types CE4110, CE4150, and CE4170,
reported as "model name : Intel(R) Atom(TM) CPU CE41{1|5|7}0 @ 1.{2|6}0GHz"
with model 28 (0x1c) and stepping 10 (0x0a). Add the three known variants
to the tjmax table.

Signed-off-by: Guenter Roeck 
Acked-by: Jean Delvare 
Signed-off-by: Ben Hutchings 
Cc: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman

hwmon: (coretemp) Add support for Atom D2000 and N2000 series CPU models

2014-04-14T13:44:31+00:00

commit 5592906f8b01282ea3c2acaf641fd067ad4bb3dc upstream.

Document the Atom series D2000 and N2000 (Cedar Trail) as being supported.
List and set TjMax for those series.

Cc: Fenghua Yu 
Cc: "R, Durgadoss" 
Signed-off-by: Guenter Roeck 
Signed-off-by: Jean Delvare 
Signed-off-by: Ben Hutchings 
Cc: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman

hwmon: (coretemp) Improve support of recent Atom CPU models

2014-04-14T13:44:31+00:00

commit fcc14ac1a86931f38da047cf8fb634c6db7b58bc upstream.

Document the new Atom series (Tunnel Creek and Medfield) as being
supported, and list TjMax for the Atom E600 series.

Also enable the Atom tjmax heuristic for these Atom CPU models.

Signed-off-by: Jean Delvare 
Reviewed-by: Guenter Roeck 
Cc: Alexander Stein 
Cc: Fenghua Yu 
Cc: "R, Durgadoss" 
Signed-off-by: Ben Hutchings 
Cc: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: imx51-babbage: fix esdhc cd/wp properties

2014-04-14T13:44:19+00:00

commit a46d2619d7180bda12bad2bf15bbd0731dfc2dcf upstream.

The binding doc and dts use properties "fsl,{cd,wp}-internal" while
esdhc driver uses "fsl,{cd,wp}-controller".  Fix binding doc and dts
to get them match driver code.

Reported-by: Chris Ball 
Signed-off-by: Shawn Guo 
Acked-by: Chris Ball 
Signed-off-by: Ben Hutchings 
Cc: Yang Yingliang 
Signed-off-by: Greg Kroah-Hartman

i2c: i801: SMBus patch for Intel Avoton DeviceIDs

2013-12-12T06:34:11+00:00

commit c2db409cbc8751ccc7e6d2cc2e41af0d12ea637f upstream.

This patch adds the PCU SMBus DeviceID for the Intel Avoton SOC.

Signed-off-by: Seth Heasley 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Cc: "Ong, Boon Leong" 
Signed-off-by: Greg Kroah-Hartman

vsprintf: check real user/group id for %pK

2013-12-04T18:50:14+00:00

commit 312b4e226951f707e120b95b118cbc14f3d162b2 upstream.

Some setuid binaries will allow reading of files which have read
permission by the real user id.  This is problematic with files which
use %pK because the file access permission is checked at open() time,
but the kptr_restrict setting is checked at read() time.  If a setuid
binary opens a %pK file as an unprivileged user, and then elevates
permissions before reading the file, then kernel pointer values may be
leaked.

This happens for example with the setuid pppd application on Ubuntu 12.04:

  $ head -1 /proc/kallsyms
  00000000 T startup_32

  $ pppd file /proc/kallsyms
  pppd: In file /proc/kallsyms: unrecognized option 'c1000000'

This will only leak the pointer value from the first line, but other
setuid binaries may leak more information.

Fix this by adding a check that in addition to the current process having
CAP_SYSLOG, that effective user and group ids are equal to the real ids.
If a setuid binary reads the contents of a file which uses %pK then the
pointer values will be printed as NULL if the real user is unprivileged.

Update the sysctl documentation to reflect the changes, and also correct
the documentation to state the kptr_restrict=0 is the default.

This is a only temporary solution to the issue.  The correct solution is
to do the permission check at open() time on files, and to replace %pK
with a function which checks the open() time permission.  %pK uses in
printk should be removed since no sane permission check can be done, and
instead protected by using dmesg_restrict.

Signed-off-by: Ryan Mallon 
Cc: Kees Cook 
Cc: Alexander Viro 
Cc: Joe Perches 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

doc, kernel-parameters: Document 'console=hvc'

2013-03-03T22:06:38+00:00

commit a2fd6419174470f5ae6383f5037d0ee21ed9833f upstream.

Both the PowerPC hypervisor and Xen hypervisor can utilize the
hvc driver.

Signed-off-by: Konrad Rzeszutek Wilk 
Link: http://lkml.kernel.org/r/1361825650-14031-3-git-send-email-konrad.wilk@oracle.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

doc, xen: Mention 'earlyprintk=xen' in the documentation.

2013-03-03T22:06:38+00:00

commit 2482a92e7d17187301d7313cfe5021b13393a0b4 upstream.

The earlyprintk for Xen PV guests utilizes a simple hypercall
(console_io) to provide output to Xen emergency console.

Note that the Xen hypervisor should be booted with 'loglevel=all'
to output said information.

Reported-by: H. Peter Anvin 
Signed-off-by: Konrad Rzeszutek Wilk 
Link: http://lkml.kernel.org/r/1361825650-14031-2-git-send-email-konrad.wilk@oracle.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

rbd: kill create_snap sysfs entry

2013-01-17T16:51:20+00:00

Josh proposed the following change, and I don't think I could
explain it any better than he did:

    From: Josh Durgin 
    Date: Tue, 24 Jul 2012 14:22:11 -0700
    To: ceph-devel 
    Message-ID: <500F1203.9050605@inktank.com>
    From: Josh Durgin 


    Right now the kernel still has one piece of rbd management
    duplicated from the rbd command line tool: snapshot creation.
    There's nothing special about snapshot creation that makes it
    advantageous to do from the kernel, so I'd like to remove the
    create_snap sysfs interface.  That is,
	/sys/bus/rbd/devices//create_snap
    would be removed.

    Does anyone rely on the sysfs interface for creating rbd
    snapshots?  If so, how hard would it be to replace with:

	rbd snap create pool/image@snap

    Is there any benefit to the sysfs interface that I'm missing?

    Josh

This patch implements this proposal, removing the code that
implements the "snap_create" sysfs interface for rbd images.
As a result, quite a lot of other supporting code goes away.

[elder@inktank.com: commented out rbd_req_sync_exec() to avoid warning]

Suggested-by: Josh Durgin 
Signed-off-by: Alex Elder 
Reviewed-by: Josh Durgin 
(based on commit 02cdb02ceab1f3dd9ac2bc899fc51f0e0e744782)

tcp: implement RFC 5961 3.2

2013-01-11T17:07:14+00:00

[ Upstream commit 282f23c6ee343126156dd41218b22ece96d747e3 ]

Implement the RFC 5691 mitigation against Blind
Reset attack using RST bit.

Idea is to validate incoming RST sequence,
to match RCV.NXT value, instead of previouly accepted
window : (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND)

If sequence is in window but not an exact match, send
a "challenge ACK", so that the other part can resend an
RST with the appropriate sequence.

Add a new sysctl, tcp_challenge_ack_limit, to limit
number of challenge ACK sent per second.

Add a new SNMP counter to count number of challenge acks sent.
(netstat -s | grep TCPChallengeACK)

Signed-off-by: Eric Dumazet 
Cc: Kiran Kumar Kella 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman