Merge branch 'linus' into x86/urgent

Contact:	linux-mtd@lists.infradead.org

Description:

		This allows the user to examine and adjust the criteria by which

		mtd returns -EUCLEAN from mtd_read().  If the maximum number of

		bit errors that were corrected on any single region comprising

		an ecc step (as reported by the driver) equals or exceeds this

		value, -EUCLEAN is returned.  Otherwise, absent an error, 0 is

		returned.  Higher layers (e.g., UBI) use this return code as an

		indication that an erase block may be degrading and should be

		scrutinized as a candidate for being marked as bad.

		mtd returns -EUCLEAN from mtd_read() and mtd_read_oob().  If the

		maximum number of bit errors that were corrected on any single

		region comprising an ecc step (as reported by the driver) equals

		or exceeds this value, -EUCLEAN is returned.  Otherwise, absent

		an error, 0 is returned.  Higher layers (e.g., UBI) use this

		return code as an indication that an erase block may be

		degrading and should be scrutinized as a candidate for being

		marked as bad.

		The initial value may be specified by the flash device driver.

		If not, then the default value is ecc_strength.

		block degradation, but high enough to avoid the consequences of

		a persistent return value of -EUCLEAN on devices where sticky

		bitflips occur.  Note that if bitflip_threshold exceeds

		ecc_strength, -EUCLEAN is never returned by mtd_read().

		ecc_strength, -EUCLEAN is never returned by the read operations.

		Conversely, if bitflip_threshold is zero, -EUCLEAN is always

		returned, absent a hard error.

	    from RGB to Y'CbCr color space.

	    </entry>

	  </row>

	  <row id = "v4l2-jpeg-chroma-subsampling">

	  <row>

	    <entrytbl spanname="descr" cols="2">

	      <tbody valign="top">

		<row>

	    processing controls. These controls are described in <xref

	    linkend="image-process-controls" />.</entry>

	  </row>

	  <row>

	    <entry><constant>V4L2_CTRL_CLASS_JPEG</constant></entry>

	    <entry>0x9d0000</entry>

	    <entry>The class containing JPEG compression controls.

These controls are described in <xref

		linkend="jpeg-controls" />.</entry>

	  </row>

	</tbody>

      </tgroup>

    </table>

		when publicizing a pointer to a structure that can

		be traversed by an RCU read-side critical section.

5.	If call_rcu(), or a related primitive such as call_rcu_bh() or

	call_rcu_sched(), is used, the callback function must be

	written to be called from softirq context.  In particular,

5.	If call_rcu(), or a related primitive such as call_rcu_bh(),

	call_rcu_sched(), or call_srcu() is used, the callback function

	must be written to be called from softirq context.  In particular,

	it cannot block.

6.	Since synchronize_rcu() can block, it cannot be called from

	updater uses call_rcu_sched() or synchronize_sched(), then

	the corresponding readers must disable preemption, possibly

	by calling rcu_read_lock_sched() and rcu_read_unlock_sched().

	If the updater uses synchronize_srcu(), the the corresponding

	readers must use srcu_read_lock() and srcu_read_unlock(),

	and with the same srcu_struct.	The rules for the expedited

	primitives are the same as for their non-expedited counterparts.

	Mixing things up will result in confusion and broken kernels.

	If the updater uses synchronize_srcu() or call_srcu(),

	the the corresponding readers must use srcu_read_lock() and

	srcu_read_unlock(), and with the same srcu_struct.  The rules for

	the expedited primitives are the same as for their non-expedited

	counterparts.  Mixing things up will result in confusion and

	broken kernels.

	One exception to this rule: rcu_read_lock() and rcu_read_unlock()

	may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()

	victim CPU from ever going offline.)

14.	SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(),

	synchronize_srcu(), and synchronize_srcu_expedited()) may only

	be invoked from process context.  Unlike other forms of RCU, it

	-is- permissible to block in an SRCU read-side critical section

	(demarked by srcu_read_lock() and srcu_read_unlock()), hence the

	"SRCU": "sleepable RCU".  Please note that if you don't need

	to sleep in read-side critical sections, you should be using

	RCU rather than SRCU, because RCU is almost always faster and

	easier to use than is SRCU.

	synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu())

	may only be invoked from process context.  Unlike other forms of

	RCU, it -is- permissible to block in an SRCU read-side critical

	section (demarked by srcu_read_lock() and srcu_read_unlock()),

	hence the "SRCU": "sleepable RCU".  Please note that if you

	don't need to sleep in read-side critical sections, you should be

	using RCU rather than SRCU, because RCU is almost always faster

	and easier to use than is SRCU.

	If you need to enter your read-side critical section in a

	hardirq or exception handler, and then exit that same read-side

	cleanup_srcu_struct().	These are passed a "struct srcu_struct"

	that defines the scope of a given SRCU domain.	Once initialized,

	the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()

	synchronize_srcu(), and synchronize_srcu_expedited().  A given

	synchronize_srcu() waits only for SRCU read-side critical

	synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu().

	A given synchronize_srcu() waits only for SRCU read-side critical

	sections governed by srcu_read_lock() and srcu_read_unlock()

	calls that have been passed the same srcu_struct.  This property

	is what makes sleeping read-side critical sections tolerable --

	requiring SRCU's read-side deadlock immunity or low read-side

	realtime latency.

	Note that, rcu_assign_pointer() relates to SRCU just as they do

	Note that, rcu_assign_pointer() relates to SRCU just as it does

	to other forms of RCU.

15.	The whole point of call_rcu(), synchronize_rcu(), and friends

   2. Execute rcu_barrier().

   3. Allow the module to be unloaded.

Quick Quiz #1: Why is there no srcu_barrier()?

The rcutorture module makes use of rcu_barrier in its exit function

as follows:

Then lines 55-62 print status and do operation-specific cleanup, and

then return, permitting the module-unload operation to be completed.

Quick Quiz #2: Is there any other situation where rcu_barrier() might

Quick Quiz #1: Is there any other situation where rcu_barrier() might

	be required?

Your module might have additional complications. For example, if your

 4 complete(&rcu_barrier_completion);

 5 }

Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes

Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes

	immediately (thus incrementing rcu_barrier_cpu_count to the

	value one), but the other CPU's rcu_barrier_func() invocations

	are delayed for a full grace period? Couldn't this result in

Answers to Quick Quizzes

Quick Quiz #1: Why is there no srcu_barrier()?

Answer: Since there is no call_srcu(), there can be no outstanding SRCU

	callbacks. Therefore, there is no need to wait for them.

Quick Quiz #2: Is there any other situation where rcu_barrier() might

Quick Quiz #1: Is there any other situation where rcu_barrier() might

	be required?

Answer: Interestingly enough, rcu_barrier() was not originally

	implementing rcutorture, and found that rcu_barrier() solves

	this problem as well.

Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes

Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes

	immediately (thus incrementing rcu_barrier_cpu_count to the

	value one), but the other CPU's rcu_barrier_func() invocations

	are delayed for a full grace period? Couldn't this result in