Merge 4.20-rc4 into tty-next

D: Soundblaster driver fixes, ISAPnP quirk

S: California, USA

N: Jarkko Lavinen

E: jarkko.lavinen@nokia.com

D: OMAP MMC support

N: Jonathan Layes

D: ARPD support

S: North Little Rock, Arkansas 72115

S: USA

N: Christopher Li

E: sparse@chrisli.org

D: Sparse maintainer 2009 - 2018

N: Stephan Linz

E: linz@mazet.de

E: Stephan.Linz@gmx.de

					prevent spurious wakeup);

				n = USB_QUIRK_DELAY_CTRL_MSG (Device needs a

					pause after every control message);

				o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra

					delay after resetting its port);

			Example: quirks=0781:5580:bk,0a5c:5834:gij

	usbhid.mousepoll=

a governor ``sysfs`` interface to it.  Next, the governor is started by

invoking its ``->start()`` callback.

That callback it expected to register per-CPU utilization update callbacks for

That callback is expected to register per-CPU utilization update callbacks for

all of the online CPUs belonging to the given policy with the CPU scheduler.

The utilization update callbacks will be invoked by the CPU scheduler on

important events, like task enqueue and dequeue, on every iteration of the

The security list is not a disclosure channel.  For that, see Coordination

below.

Once a robust fix has been developed, our preference is to release the

fix in a timely fashion, treating it no differently than any of the other

thousands of changes and fixes the Linux kernel project releases every

month.

However, at the request of the reporter, we will postpone releasing the

fix for up to 5 business days after the date of the report or after the

embargo has lifted; whichever comes first.  The only exception to that

rule is if the bug is publicly known, in which case the preference is to

release the fix as soon as it's available.

Once a robust fix has been developed, the release process starts.  Fixes

for publicly known bugs are released immediately.

Although our preference is to release fixes for publicly undisclosed bugs

as soon as they become available, this may be postponed at the request of

the reporter or an affected party for up to 7 calendar days from the start

of the release process, with an exceptional extension to 14 calendar days

if it is agreed that the criticality of the bug requires more time.  The

only valid reason for deferring the publication of a fix is to accommodate

the logistics of QA and large scale rollouts which require release

coordination.

Whilst embargoed information may be shared with trusted individuals in

order to develop a fix, such information will not be published alongside

new entry and return the previous entry stored at that index.  You can

use :c:func:`xa_erase` instead of calling :c:func:`xa_store` with a

``NULL`` entry.  There is no difference between an entry that has never

been stored to and one that has most recently had ``NULL`` stored to it.

been stored to, one that has been erased and one that has most recently

had ``NULL`` stored to it.

You can conditionally replace an entry at an index by using

:c:func:`xa_cmpxchg`.  Like :c:func:`cmpxchg`, it will only succeed if

indices.  Storing into one index may result in the entry retrieved by

some, but not all of the other indices changing.

Sometimes you need to ensure that a subsequent call to :c:func:`xa_store`

will not need to allocate memory.  The :c:func:`xa_reserve` function

will store a reserved entry at the indicated index.  Users of the normal

API will see this entry as containing ``NULL``.  If you do not need to

use the reserved entry, you can call :c:func:`xa_release` to remove the

unused entry.  If another user has stored to the entry in the meantime,

:c:func:`xa_release` will do nothing; if instead you want the entry to

become ``NULL``, you should use :c:func:`xa_erase`.

If all entries in the array are ``NULL``, the :c:func:`xa_empty` function

will return ``true``.

Finally, you can remove all entries from an XArray by calling

:c:func:`xa_destroy`.  If the XArray entries are pointers, you may wish

to free the entries first.  You can do this by iterating over all present

entries in the XArray using the :c:func:`xa_for_each` iterator.

ID assignment

-------------

Allocating XArrays

------------------

If you use :c:func:`DEFINE_XARRAY_ALLOC` to define the XArray, or

initialise it by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,

the XArray changes to track whether entries are in use or not.

You can call :c:func:`xa_alloc` to store the entry at any unused index

in the XArray.  If you need to modify the array from interrupt context,

you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable

interrupts while allocating the ID.  Unlike :c:func:`xa_store`, allocating

a ``NULL`` pointer does not delete an entry.  Instead it reserves an

entry like :c:func:`xa_reserve` and you can release it using either

:c:func:`xa_erase` or :c:func:`xa_release`.  To use ID assignment, the

XArray must be defined with :c:func:`DEFINE_XARRAY_ALLOC`, or initialised

by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,

interrupts while allocating the ID.

Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert`

will mark the entry as being allocated.  Unlike a normal XArray, storing

``NULL`` will mark the entry as being in use, like :c:func:`xa_reserve`.

To free an entry, use :c:func:`xa_erase` (or :c:func:`xa_release` if

you only want to free the entry if it's ``NULL``).

You cannot use ``XA_MARK_0`` with an allocating XArray as this mark

is used to track whether an entry is free or not.  The other marks are

available for your use.

Memory allocation

-----------------

Takes xa_lock internally:

 * :c:func:`xa_store`

 * :c:func:`xa_store_bh`

 * :c:func:`xa_store_irq`

 * :c:func:`xa_insert`

 * :c:func:`xa_erase`

 * :c:func:`xa_erase_bh`

 * :c:func:`xa_alloc`

 * :c:func:`xa_alloc_bh`

 * :c:func:`xa_alloc_irq`

 * :c:func:`xa_reserve`

 * :c:func:`xa_reserve_bh`

 * :c:func:`xa_reserve_irq`

 * :c:func:`xa_destroy`

 * :c:func:`xa_set_mark`

 * :c:func:`xa_clear_mark`

 * :c:func:`__xa_erase`

 * :c:func:`__xa_cmpxchg`

 * :c:func:`__xa_alloc`

 * :c:func:`__xa_reserve`

 * :c:func:`__xa_set_mark`

 * :c:func:`__xa_clear_mark`

using :c:func:`xa_lock_irqsave` in both the interrupt handler and process

context, or :c:func:`xa_lock_irq` in process context and :c:func:`xa_lock`

in the interrupt handler.  Some of the more common patterns have helper

functions such as :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`.

functions such as :c:func:`xa_store_bh`, :c:func:`xa_store_irq`,

:c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`.

Sometimes you need to protect access to the XArray with a mutex because

that lock sits above another mutex in the locking hierarchy.  That does

     - :c:func:`xa_is_zero`

     - Zero entries appear as ``NULL`` through the Normal API, but occupy

       an entry in the XArray which can be used to reserve the index for

       future use.

       future use.  This is used by allocating XArrays for allocated entries

       which are ``NULL``.

Other internal entries may be added in the future.  As far as possible, they

will be handled by :c:func:`xas_retry`.