<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include, branch v3.15.5</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/i915: provide interface for audio driver to query cdclk</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2014-07-04T02:00:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8143820319a5e7d617c122c70b58e1fdbd1b2c6e'/>
<id>8143820319a5e7d617c122c70b58e1fdbd1b2c6e</id>
<content type='text'>
commit c149dcb5c60bfea8871f16dfcc0690255eeb825f upstream.

For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private interface for the
audio driver to query CDCLK.

This is a stopgap solution until a more generic interface between audio
and display drivers has been implemented.

Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Damien Lespiau &lt;damien.lespiau@intel.com&gt;
Signed-off-by: Mengdong Lin &lt;mengdong.lin@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c149dcb5c60bfea8871f16dfcc0690255eeb825f upstream.

For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private interface for the
audio driver to query CDCLK.

This is a stopgap solution until a more generic interface between audio
and display drivers has been implemented.

Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Damien Lespiau &lt;damien.lespiau@intel.com&gt;
Signed-off-by: Mengdong Lin &lt;mengdong.lin@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915, HD-audio: Don't continue probing when nomodeset is given</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2014-06-13T13:14:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ab2a211c3d3d2f871f79f0a48c73b8df653219ea'/>
<id>ab2a211c3d3d2f871f79f0a48c73b8df653219ea</id>
<content type='text'>
commit 74b0c2d75fb4cc89173944e6d8f9eb47aca0c343 upstream.

When a machine is booted with nomodeset option, i915 driver skips the
whole initialization.  Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_well() wrongly but still continues probing,
even though it doesn't work at all.

In this patch, both functions are changed to return an error in case
of uninitialized state instead of WARN_ON(), so that HD-audio driver
can give up HDMI controller initialization at the right time.

Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 74b0c2d75fb4cc89173944e6d8f9eb47aca0c343 upstream.

When a machine is booted with nomodeset option, i915 driver skips the
whole initialization.  Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_well() wrongly but still continues probing,
even though it doesn't work at all.

In this patch, both functions are changed to return an error in case
of uninitialized state instead of WARN_ON(), so that HD-audio driver
can give up HDMI controller initialization at the right time.

Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: f_fs: resurect usb_functionfs_descs_head structure</title>
<updated>2014-07-09T18:21:24+00:00</updated>
<author>
<name>Michal Nazarewicz</name>
<email>mina86@mina86.com</email>
</author>
<published>2014-06-13T13:38:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=40c409dcedd38eb34785ba0cfde6de0936c56a2e'/>
<id>40c409dcedd38eb34785ba0cfde6de0936c56a2e</id>
<content type='text'>
commit 09122141785348bf9539762a5f5dbbae3761c783 upstream.

Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools.  Its removel in commit
[ac8dde1: “Add flags to descriptors block”] was an oversight
leading to build breakage for such tools.

Bring it back so that old user space tools can still be build
without problems on newer kernel versions.

Reported-by: Lad, Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Reported-by: Krzysztof Opasiak &lt;k.opasiak@samsung.com&gt;
Signed-off-by: Michal Nazarewicz &lt;mina86@mina86.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 09122141785348bf9539762a5f5dbbae3761c783 upstream.

Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools.  Its removel in commit
[ac8dde1: “Add flags to descriptors block”] was an oversight
leading to build breakage for such tools.

Bring it back so that old user space tools can still be build
without problems on newer kernel versions.

Reported-by: Lad, Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Reported-by: Krzysztof Opasiak &lt;k.opasiak@samsung.com&gt;
Signed-off-by: Michal Nazarewicz &lt;mina86@mina86.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb-storage/SCSI: Add broken_fua blacklist flag</title>
<updated>2014-07-09T18:21:23+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2014-06-30T15:04:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1154a920603b7bfc7c7d0d27b1abd67d0e56227'/>
<id>b1154a920603b7bfc7c7d0d27b1abd67d0e56227</id>
<content type='text'>
commit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream.

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs.  This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Michael Büsch &lt;m@bues.ch&gt;
Tested-by: Michael Büsch &lt;m@bues.ch&gt;
Acked-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
CC: Matthew Dharm &lt;mdharm-usb@one-eyed-alien.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream.

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs.  This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Michael Büsch &lt;m@bues.ch&gt;
Tested-by: Michael Büsch &lt;m@bues.ch&gt;
Acked-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
CC: Matthew Dharm &lt;mdharm-usb@one-eyed-alien.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: use the scsi data buffer length to extract transfer size</title>
<updated>2014-07-09T18:21:23+00:00</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2014-06-24T14:59:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=65e98a83a95c5c3e5b6e686173054a557626909c'/>
<id>65e98a83a95c5c3e5b6e686173054a557626909c</id>
<content type='text'>
commit 5616b0a46ed82eb9a093f752fc4d7bd3cc688583 upstream.

Commit 8846bab180fa introduced a helper that can be used to query the
wire transfer size for a SCSI command taking protection information into
account.

However, some commands do not have a 1:1 mapping between the block range
they work on and the payload size (discard, write same). After the
scatterlist has been set up these requests use __data_len to store the
number of bytes to report completion on. This means that callers of
scsi_transfer_length() would get the wrong byte count for these types of
requests.

To overcome this we make scsi_transfer_length() use the scatterlist
length in the scsi_data_buffer as basis for the wire transfer
calculation instead of __data_len.

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Debugged-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Fixes: d77e65350f2d82dfa0557707d505711f5a43c8fd
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5616b0a46ed82eb9a093f752fc4d7bd3cc688583 upstream.

Commit 8846bab180fa introduced a helper that can be used to query the
wire transfer size for a SCSI command taking protection information into
account.

However, some commands do not have a 1:1 mapping between the block range
they work on and the payload size (discard, write same). After the
scatterlist has been set up these requests use __data_len to store the
number of bytes to report completion on. This means that callers of
scsi_transfer_length() would get the wrong byte count for these types of
requests.

To overcome this we make scsi_transfer_length() use the scatterlist
length in the scsi_data_buffer as basis for the wire transfer
calculation instead of __data_len.

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Debugged-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Fixes: d77e65350f2d82dfa0557707d505711f5a43c8fd
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Fix syscall_*regfunc() vs copy_process() race</title>
<updated>2014-07-07T01:59:12+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2014-04-13T18:58:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=22e7649524323c35d868c639f349164fb8ef8455'/>
<id>22e7649524323c35d868c639f349164fb8ef8455</id>
<content type='text'>
commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.

syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.

Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.

Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com

Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.

syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.

Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.

Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com

Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ptrace,x86: force IRET path after a ptrace_stop()</title>
<updated>2014-07-07T01:59:12+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-07-03T19:43:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ac79fd540a0282460a22955753056c4a636b620b'/>
<id>ac79fd540a0282460a22955753056c4a636b620b</id>
<content type='text'>
commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values.  That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'.  Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Acked-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values.  That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'.  Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Acked-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Clearly distinguish mgmt LTK type from authenticated property</title>
<updated>2014-07-01T03:14:03+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2014-05-23T10:19:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8556876847effb03ca33334464c2854bdd3f0ed8'/>
<id>8556876847effb03ca33334464c2854bdd3f0ed8</id>
<content type='text'>
commit d7b2545023ecfde94d3ea9c03c5480ac18da96c9 upstream.

On the mgmt level we have a key type parameter which currently accepts
two possible values: 0x00 for unauthenticated and 0x01 for
authenticated. However, in the internal struct smp_ltk representation we
have an explicit "authenticated" boolean value.

To make this distinction clear, add defines for the possible mgmt values
and do conversion to and from the internal authenticated value.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d7b2545023ecfde94d3ea9c03c5480ac18da96c9 upstream.

On the mgmt level we have a key type parameter which currently accepts
two possible values: 0x00 for unauthenticated and 0x01 for
authenticated. However, in the internal struct smp_ltk representation we
have an explicit "authenticated" boolean value.

To make this distinction clear, add defines for the possible mgmt values
and do conversion to and from the internal authenticated value.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>genirq: Sanitize spurious interrupt detection of threaded irqs</title>
<updated>2014-07-01T03:14:01+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2013-03-07T13:53:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a23f966716ec70c47083c06e9ddbf3d4fbc80c33'/>
<id>a23f966716ec70c47083c06e9ddbf3d4fbc80c33</id>
<content type='text'>
commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream.

Till reported that the spurious interrupt detection of threaded
interrupts is broken in two ways:

- note_interrupt() is called for each action thread of a shared
  interrupt line. That's wrong as we are only interested whether none
  of the device drivers felt responsible for the interrupt, but by
  calling multiple times for a single interrupt line we account
  IRQ_NONE even if one of the drivers felt responsible.

- note_interrupt() when called from the thread handler is not
  serialized. That leaves the members of irq_desc which are used for
  the spurious detection unprotected.

To solve this we need to defer the spurious detection of a threaded
interrupt to the next hardware interrupt context where we have
implicit serialization.

If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
check whether the previous interrupt requested a deferred check. If
not, we request a deferred check for the next hardware interrupt and
return.

If set, we check whether one of the interrupt threads signaled
success. Depending on this information we feed the result into the
spurious detector.

If one primary handler of a shared interrupt returns IRQ_HANDLED we
disable the deferred check of irq threads on the same line, as we have
found at least one device driver who cared.

Reported-by: Till Straumann &lt;strauman@slac.stanford.edu&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Austin Schuh &lt;austin@peloton-tech.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Cc: Pavel Pisa &lt;pisa@cmp.felk.cvut.cz&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: linux-can@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream.

Till reported that the spurious interrupt detection of threaded
interrupts is broken in two ways:

- note_interrupt() is called for each action thread of a shared
  interrupt line. That's wrong as we are only interested whether none
  of the device drivers felt responsible for the interrupt, but by
  calling multiple times for a single interrupt line we account
  IRQ_NONE even if one of the drivers felt responsible.

- note_interrupt() when called from the thread handler is not
  serialized. That leaves the members of irq_desc which are used for
  the spurious detection unprotected.

To solve this we need to defer the spurious detection of a threaded
interrupt to the next hardware interrupt context where we have
implicit serialization.

If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
check whether the previous interrupt requested a deferred check. If
not, we request a deferred check for the next hardware interrupt and
return.

If set, we check whether one of the interrupt threads signaled
success. Depending on this information we feed the result into the
spurious detector.

If one primary handler of a shared interrupt returns IRQ_HANDLED we
disable the deferred check of irq threads on the same line, as we have
found at least one device driver who cared.

Reported-by: Till Straumann &lt;strauman@slac.stanford.edu&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Austin Schuh &lt;austin@peloton-tech.com&gt;
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Cc: Pavel Pisa &lt;pisa@cmp.felk.cvut.cz&gt;
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Cc: linux-can@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi_cmnd: Introduce scsi_transfer_length helper</title>
<updated>2014-07-01T03:14:00+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2014-06-11T09:09:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff04e8f8acb5ccc792d905b58f5e3353f4e26753'/>
<id>ff04e8f8acb5ccc792d905b58f5e3353f4e26753</id>
<content type='text'>
commit 8846bab180fa2bcfe02d4ba5288fbaba12c8f4f3 upstream.

In case protection information exists on the wire
scsi transports should include it in the transfer
byte count (even if protection information does not
exist in the host memory space). This helper will
compute the total transfer length from the scsi
command data length and protection attributes.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8846bab180fa2bcfe02d4ba5288fbaba12c8f4f3 upstream.

In case protection information exists on the wire
scsi transports should include it in the transfer
byte count (even if protection information does not
exist in the host memory space). This helper will
compute the total transfer length from the scsi
command data length and protection attributes.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
