linux-toradex.git/include, branch v3.2.1-rt9

Merge commit 'v3.2.1' into rt-3.2.1-rt9

2012-01-13T04:11:05+00:00

usb: ch9: fix up MaxStreams helper

2012-01-12T19:29:43+00:00

commit 18b7ede5f7ee2092aedcb578d3ac30bd5d4fc23c upstream.

[ removed the dwc3 portion of the patch as it didn't apply to
older kernels - gregkh]

According to USB 3.0 Specification Table 9-22, if
bmAttributes [4:0] are set to zero, it means "no
streams supported", but the way this helper was
defined on Linux, we will *always* have one stream
which might cause several problems.

For example on DWC3, we would tell the controller
endpoint has streams enabled and yet start transfers
with Stream ID set to 0, which would goof up the host
side.

While doing that, convert the macro to an inline
function due to the different checks we now need.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

usb: fix number of mapped SG DMA entries

2012-01-12T19:29:43+00:00

commit bc677d5b64644c399cd3db6a905453e611f402ab upstream.

Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.

This fixes warnings like the following when using USB storage devices:
 ------------[ cut here ]------------
 WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
 ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
 Modules linked in: ohci_hcd ehci_hcd
 Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
 Call Trace:
    [] warn_slowpath_common+0x80/0x98
  [] warn_slowpath_fmt+0x41/0x43
  [] check_unmap+0x4e4/0x695
  [] ? trace_hardirqs_off+0xd/0xf
  [] ? _raw_spin_unlock_irqrestore+0x33/0x50
  [] debug_dma_unmap_sg+0xeb/0x117
  [] usb_hcd_unmap_urb_for_dma+0x71/0x188
  [] unmap_urb_for_dma+0x20/0x22
  [] usb_hcd_giveback_urb+0x5d/0xc0
  [] ehci_urb_done+0xf7/0x10c [ehci_hcd]
  [] qh_completions+0x429/0x4bd [ehci_hcd]
  [] ehci_work+0x95/0x9c0 [ehci_hcd]
  ...
 ---[ end trace f29ac88a5a48c580 ]---
 Mapped at:
  [] debug_dma_map_sg+0x45/0x139
  [] usb_hcd_map_urb_for_dma+0x22e/0x478
  [] usb_hcd_submit_urb+0x63f/0x6fa
  [] usb_submit_urb+0x2c7/0x2de
  [] usb_sg_wait+0x55/0x161

Signed-off-by: Clemens Ladisch 
Signed-off-by: Greg Kroah-Hartman

Merge commit 'v3.2' into rt-3.2-rt9

2012-01-05T18:51:32+00:00

security: Fix security_old_inode_init_security() when CONFIG_SECURITY is not set

2012-01-04T00:12:19+00:00

Commit 1e39f384bb01 ("evm: fix build problems") makes the stub version
of security_old_inode_init_security() return 0 when CONFIG_SECURITY is
not set.

But that makes callers such as reiserfs_security_init() assume that
security_old_inode_init_security() has set name, value, and len
arguments properly - but security_old_inode_init_security() left them
uninitialized which then results in interesting failures.

Revert security_old_inode_init_security() to the old behavior of
returning EOPNOTSUPP since both callers (reiserfs and ocfs2) handle this
just fine.

[ Also fixed the S_PRIVATE(inode) case of the actual non-stub
  security_old_inode_init_security() function to return EOPNOTSUPP
  for the same reason, as pointed out by Mimi Zohar.

  It got incorrectly changed to match the new function in commit
  fb88c2b6cbb1: "evm: fix security/security_old_init_security return
  code".   - Linus ]

Reported-by: Jorge Bastos 
Acked-by: James Morris 
Acked-by: Mimi Zohar 
Signed-off-by: Jan Kara 
Signed-off-by: Linus Torvalds

Merge commit 'v3.2-rc7' into rt-3.2-rc7-rt9

2012-01-03T16:47:33+00:00

ipvs: try also real server with port 0 in backup server

2011-12-31T15:06:29+00:00

	We should not forget to try for real server with port 0
in the backup server when processing the sync message. We should
do it in all cases because the backup server can use different
forwarding method.

Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Pablo Neira Ayuso

procfs: do not confuse jiffies with cputime64_t

2011-12-30T00:31:57+00:00

Commit 2a95ea6c0d129b4 ("procfs: do not overflow get_{idle,iowait}_time
for nohz") did not take into account that one some architectures jiffies
and cputime use different units.

This causes get_idle_time() to return numbers in the wrong units, making
the idle time fields in /proc/stat wrong.

Instead of converting the usec value returned by
get_cpu_{idle,iowait}_time_us to units of jiffies, use the new function
usecs_to_cputime64 to convert it to the correct unit of cputime64_t.

Signed-off-by: Andreas Schwab 
Acked-by: Michal Hocko 
Cc: Arnd Bergmann 
Cc: "Artem S. Tashkinov" 
Cc: Dave Jones 
Cc: Alexey Dobriyan 
Cc: Thomas Gleixner 
Cc: "Luck, Tony" 
Cc: Benjamin Herrenschmidt 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

wait-simple: Simple waitqueue implementation

2011-12-28T22:25:51+00:00

wait_queue is a swiss army knife and in most of the cases the
complexity is not needed. For RT waitqueues are a constant source of
trouble as we can't convert the head lock to a raw spinlock due to
fancy and long lasting callbacks.

Provide a slim version, which allows RT to replace wait queues. This
should go mainline as well, as it lowers memory consumption and
runtime overhead.

Signed-off-by: Thomas Gleixner

sysrq: Allow immediate Magic SysRq output for PREEMPT_RT_FULL

2011-12-28T22:25:51+00:00

Add a CONFIG option to allow the output from Magic SysRq to be output
immediately, even if this causes large latencies.

If PREEMPT_RT_FULL, printk() will not try to acquire the console lock
when interrupts or preemption are disabled.  If the console lock is
not acquired the printk() output will be buffered, but will not be
output immediately. Some drivers call into the Magic SysRq code
with interrupts or preemption disabled, so the output of Magic SysRq
will be buffered instead of printing immediately if this option is
not selected.

Even with this option selected, Magic SysRq output will be delayed
if the attempt to acquire the console lock fails.

Signed-off-by: Frank Rowand 
Link: http://lkml.kernel.org/r/4E7CEF60.5020508@am.sony.com
Signed-off-by: Thomas Gleixner