Merge branch 'pci/msi-affinity' into next
Conflicts: drivers/nvme/host/pci.c
This commit is contained in:
commit
9454c23852
1008 changed files with 9995 additions and 6387 deletions
6
.mailmap
6
.mailmap
|
|
@ -21,6 +21,7 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
|
|||
Andrew Morton <akpm@linux-foundation.org>
|
||||
Andrew Vasquez <andrew.vasquez@qlogic.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
Antoine Tenart <antoine.tenart@free-electrons.com>
|
||||
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
|
||||
Archit Taneja <archit@ti.com>
|
||||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
|
|
@ -30,6 +31,9 @@ Axel Lin <axel.lin@gmail.com>
|
|||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
Boris Brezillon <boris.brezillon@free-electrons.com>
|
||||
Boris Brezillon <boris.brezillon@free-electrons.com> <b.brezillon.dev@gmail.com>
|
||||
Boris Brezillon <boris.brezillon@free-electrons.com> <b.brezillon@overkiz.com>
|
||||
Brian Avery <b.avery@hp.com>
|
||||
Brian King <brking@us.ibm.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
|
|
@ -89,6 +93,7 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
|||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com> <mchehab@infradead.org> <mchehab@redhat.com> <m.chehab@samsung.com> <mchehab@osg.samsung.com> <mchehab@s-opensource.com>
|
||||
Mayuresh Janorkar <mayur@ti.com>
|
||||
Michael Buesch <m@bues.ch>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
|
|
@ -122,6 +127,7 @@ Santosh Shilimkar <santosh.shilimkar@oracle.org>
|
|||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
S.Çağlar Onur <caglar@pardus.org.tr>
|
||||
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
|
||||
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com> <shuah.khan@hp.com> <shuahkh@osg.samsung.com> <shuah.kh@samsung.com>
|
||||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
Stephen Hemminger <shemminger@osdl.org>
|
||||
|
|
|
|||
1
CREDITS
1
CREDITS
|
|
@ -649,6 +649,7 @@ D: Configure, Menuconfig, xconfig
|
|||
|
||||
N: Mauro Carvalho Chehab
|
||||
E: m.chehab@samsung.org
|
||||
E: mchehab@osg.samsung.com
|
||||
E: mchehab@infradead.org
|
||||
D: Media subsystem (V4L/DVB) drivers and core
|
||||
D: EDAC drivers and EDAC 3.0 core rework
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/uvc.name
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: UVC function directory
|
||||
|
||||
streaming_maxburst - 0..15 (ss only)
|
||||
|
|
@ -9,37 +9,37 @@ Description: UVC function directory
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Control descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/class
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Class descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/class/ss
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Super speed control class descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/class/fs
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Full speed control class descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Terminal descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Output terminal descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output/default
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Default output terminal descriptors
|
||||
|
||||
All attributes read only:
|
||||
|
|
@ -53,12 +53,12 @@ Description: Default output terminal descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Camera terminal descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera/default
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Default camera terminal descriptors
|
||||
|
||||
All attributes read only:
|
||||
|
|
@ -75,12 +75,12 @@ Description: Default camera terminal descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/processing
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Processing unit descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/processing/default
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Default processing unit descriptors
|
||||
|
||||
All attributes read only:
|
||||
|
|
@ -94,49 +94,49 @@ Description: Default processing unit descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/header
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Control header descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/header/name
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Specific control header descriptors
|
||||
|
||||
dwClockFrequency
|
||||
bcdUVC
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Streaming descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Streaming class descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/ss
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Super speed streaming class descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/hs
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: High speed streaming class descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/fs
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Full speed streaming class descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Color matching descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching/default
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Default color matching descriptors
|
||||
|
||||
All attributes read only:
|
||||
|
|
@ -150,12 +150,12 @@ Description: Default color matching descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: MJPEG format descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Specific MJPEG format descriptors
|
||||
|
||||
All attributes read only,
|
||||
|
|
@ -174,7 +174,7 @@ Description: Specific MJPEG format descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name/name
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Specific MJPEG frame descriptors
|
||||
|
||||
dwFrameInterval - indicates how frame interval can be
|
||||
|
|
@ -196,12 +196,12 @@ Description: Specific MJPEG frame descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Uncompressed format descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Specific uncompressed format descriptors
|
||||
|
||||
bmaControls - this format's data for bmaControls in
|
||||
|
|
@ -221,7 +221,7 @@ Description: Specific uncompressed format descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name/name
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Specific uncompressed frame descriptors
|
||||
|
||||
dwFrameInterval - indicates how frame interval can be
|
||||
|
|
@ -243,12 +243,12 @@ Description: Specific uncompressed frame descriptors
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Streaming header descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header/name
|
||||
Date: Dec 2014
|
||||
KernelVersion: 3.20
|
||||
KernelVersion: 4.0
|
||||
Description: Specific streaming header descriptors
|
||||
|
||||
All attributes read only:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
What /sys/bus/iio/devices/iio:deviceX/in_proximity_raw
|
||||
What /sys/bus/iio/devices/iio:deviceX/in_proximity_input
|
||||
Date: March 2014
|
||||
KernelVersion: 3.15
|
||||
Contact: Matt Ranostay <mranostay@gmail.com>
|
||||
|
|
|
|||
|
|
@ -78,422 +78,111 @@ CONFIG_PCI_MSI option.
|
|||
|
||||
4.2 Using MSI
|
||||
|
||||
Most of the hard work is done for the driver in the PCI layer. It simply
|
||||
has to request that the PCI layer set up the MSI capability for this
|
||||
Most of the hard work is done for the driver in the PCI layer. The driver
|
||||
simply has to request that the PCI layer set up the MSI capability for this
|
||||
device.
|
||||
|
||||
4.2.1 pci_enable_msi
|
||||
To automatically use MSI or MSI-X interrupt vectors, use the following
|
||||
function:
|
||||
|
||||
int pci_enable_msi(struct pci_dev *dev)
|
||||
int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
|
||||
unsigned int max_vecs, unsigned int flags);
|
||||
|
||||
A successful call allocates ONE interrupt to the device, regardless
|
||||
of how many MSIs the device supports. The device is switched from
|
||||
pin-based interrupt mode to MSI mode. The dev->irq number is changed
|
||||
to a new number which represents the message signaled interrupt;
|
||||
consequently, this function should be called before the driver calls
|
||||
request_irq(), because an MSI is delivered via a vector that is
|
||||
different from the vector of a pin-based interrupt.
|
||||
which allocates up to max_vecs interrupt vectors for a PCI device. It
|
||||
returns the number of vectors allocated or a negative error. If the device
|
||||
has a requirements for a minimum number of vectors the driver can pass a
|
||||
min_vecs argument set to this limit, and the PCI core will return -ENOSPC
|
||||
if it can't meet the minimum number of vectors.
|
||||
|
||||
4.2.2 pci_enable_msi_range
|
||||
The flags argument should normally be set to 0, but can be used to pass the
|
||||
PCI_IRQ_NOMSI and PCI_IRQ_NOMSIX flag in case a device claims to support
|
||||
MSI or MSI-X, but the support is broken, or to pass PCI_IRQ_NOLEGACY in
|
||||
case the device does not support legacy interrupt lines.
|
||||
|
||||
int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
|
||||
By default this function will spread the interrupts around the available
|
||||
CPUs, but this feature can be disabled by passing the PCI_IRQ_NOAFFINITY
|
||||
flag.
|
||||
|
||||
This function allows a device driver to request any number of MSI
|
||||
interrupts within specified range from 'minvec' to 'maxvec'.
|
||||
To get the Linux IRQ numbers passed to request_irq() and free_irq() and the
|
||||
vectors, use the following function:
|
||||
|
||||
If this function returns a positive number it indicates the number of
|
||||
MSI interrupts that have been successfully allocated. In this case
|
||||
the device is switched from pin-based interrupt mode to MSI mode and
|
||||
updates dev->irq to be the lowest of the new interrupts assigned to it.
|
||||
The other interrupts assigned to the device are in the range dev->irq
|
||||
to dev->irq + returned value - 1. Device driver can use the returned
|
||||
number of successfully allocated MSI interrupts to further allocate
|
||||
and initialize device resources.
|
||||
int pci_irq_vector(struct pci_dev *dev, unsigned int nr);
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to request any more MSI interrupts for
|
||||
this device.
|
||||
Any allocated resources should be freed before removing the device using
|
||||
the following function:
|
||||
|
||||
This function should be called before the driver calls request_irq(),
|
||||
because MSI interrupts are delivered via vectors that are different
|
||||
from the vector of a pin-based interrupt.
|
||||
void pci_free_irq_vectors(struct pci_dev *dev);
|
||||
|
||||
It is ideal if drivers can cope with a variable number of MSI interrupts;
|
||||
there are many reasons why the platform may not be able to provide the
|
||||
exact number that a driver asks for.
|
||||
If a device supports both MSI-X and MSI capabilities, this API will use the
|
||||
MSI-X facilities in preference to the MSI facilities. MSI-X supports any
|
||||
number of interrupts between 1 and 2048. In contrast, MSI is restricted to
|
||||
a maximum of 32 interrupts (and must be a power of two). In addition, the
|
||||
MSI interrupt vectors must be allocated consecutively, so the system might
|
||||
not be able to allocate as many vectors for MSI as it could for MSI-X. On
|
||||
some platforms, MSI interrupts must all be targeted at the same set of CPUs
|
||||
whereas MSI-X interrupts can all be targeted at different CPUs.
|
||||
|
||||
There could be devices that can not operate with just any number of MSI
|
||||
interrupts within a range. See chapter 4.3.1.3 to get the idea how to
|
||||
handle such devices for MSI-X - the same logic applies to MSI.
|
||||
If a device supports neither MSI-X or MSI it will fall back to a single
|
||||
legacy IRQ vector.
|
||||
|
||||
4.2.1.1 Maximum possible number of MSI interrupts
|
||||
The typical usage of MSI or MSI-X interrupts is to allocate as many vectors
|
||||
as possible, likely up to the limit supported by the device. If nvec is
|
||||
larger than the number supported by the device it will automatically be
|
||||
capped to the supported limit, so there is no need to query the number of
|
||||
vectors supported beforehand:
|
||||
|
||||
The typical usage of MSI interrupts is to allocate as many vectors as
|
||||
possible, likely up to the limit returned by pci_msi_vec_count() function:
|
||||
|
||||
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, 1, nvec);
|
||||
}
|
||||
|
||||
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
|
||||
the value of 0 would be meaningless and could result in error.
|
||||
|
||||
Some devices have a minimal limit on number of MSI interrupts.
|
||||
In this case the function could look like this:
|
||||
|
||||
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, FOO_DRIVER_MINIMUM_NVEC, nvec);
|
||||
}
|
||||
|
||||
4.2.1.2 Exact number of MSI interrupts
|
||||
nvec = pci_alloc_irq_vectors(pdev, 1, nvec, 0);
|
||||
if (nvec < 0)
|
||||
goto out_err;
|
||||
|
||||
If a driver is unable or unwilling to deal with a variable number of MSI
|
||||
interrupts it could request a particular number of interrupts by passing
|
||||
that number to pci_enable_msi_range() function as both 'minvec' and 'maxvec'
|
||||
parameters:
|
||||
interrupts it can request a particular number of interrupts by passing that
|
||||
number to pci_alloc_irq_vectors() function as both 'min_vecs' and
|
||||
'max_vecs' parameters:
|
||||
|
||||
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, nvec, nvec);
|
||||
}
|
||||
ret = pci_alloc_irq_vectors(pdev, nvec, nvec, 0);
|
||||
if (ret < 0)
|
||||
goto out_err;
|
||||
|
||||
Note, unlike pci_enable_msi_exact() function, which could be also used to
|
||||
enable a particular number of MSI-X interrupts, pci_enable_msi_range()
|
||||
returns either a negative errno or 'nvec' (not negative errno or 0 - as
|
||||
pci_enable_msi_exact() does).
|
||||
The most notorious example of the request type described above is enabling
|
||||
the single MSI mode for a device. It could be done by passing two 1s as
|
||||
'min_vecs' and 'max_vecs':
|
||||
|
||||
4.2.1.3 Single MSI mode
|
||||
ret = pci_alloc_irq_vectors(pdev, 1, 1, 0);
|
||||
if (ret < 0)
|
||||
goto out_err;
|
||||
|
||||
The most notorious example of the request type described above is
|
||||
enabling the single MSI mode for a device. It could be done by passing
|
||||
two 1s as 'minvec' and 'maxvec':
|
||||
Some devices might not support using legacy line interrupts, in which case
|
||||
the PCI_IRQ_NOLEGACY flag can be used to fail the request if the platform
|
||||
can't provide MSI or MSI-X interrupts:
|
||||
|
||||
static int foo_driver_enable_single_msi(struct pci_dev *pdev)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, 1, 1);
|
||||
}
|
||||
nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_NOLEGACY);
|
||||
if (nvec < 0)
|
||||
goto out_err;
|
||||
|
||||
Note, unlike pci_enable_msi() function, which could be also used to
|
||||
enable the single MSI mode, pci_enable_msi_range() returns either a
|
||||
negative errno or 1 (not negative errno or 0 - as pci_enable_msi()
|
||||
does).
|
||||
4.3 Legacy APIs
|
||||
|
||||
4.2.3 pci_enable_msi_exact
|
||||
The following old APIs to enable and disable MSI or MSI-X interrupts should
|
||||
not be used in new code:
|
||||
|
||||
int pci_enable_msi_exact(struct pci_dev *dev, int nvec)
|
||||
pci_enable_msi() /* deprecated */
|
||||
pci_enable_msi_range() /* deprecated */
|
||||
pci_enable_msi_exact() /* deprecated */
|
||||
pci_disable_msi() /* deprecated */
|
||||
pci_enable_msix_range() /* deprecated */
|
||||
pci_enable_msix_exact() /* deprecated */
|
||||
pci_disable_msix() /* deprecated */
|
||||
|
||||
This variation on pci_enable_msi_range() call allows a device driver to
|
||||
request exactly 'nvec' MSIs.
|
||||
Additionally there are APIs to provide the number of supported MSI or MSI-X
|
||||
vectors: pci_msi_vec_count() and pci_msix_vec_count(). In general these
|
||||
should be avoided in favor of letting pci_alloc_irq_vectors() cap the
|
||||
number of vectors. If you have a legitimate special use case for the count
|
||||
of vectors we might have to revisit that decision and add a
|
||||
pci_nr_irq_vectors() helper that handles MSI and MSI-X transparently.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to request any more MSI interrupts for
|
||||
this device.
|
||||
4.4 Considerations when using MSIs
|
||||
|
||||
By contrast with pci_enable_msi_range() function, pci_enable_msi_exact()
|
||||
returns zero in case of success, which indicates MSI interrupts have been
|
||||
successfully allocated.
|
||||
|
||||
4.2.4 pci_disable_msi
|
||||
|
||||
void pci_disable_msi(struct pci_dev *dev)
|
||||
|
||||
This function should be used to undo the effect of pci_enable_msi_range().
|
||||
Calling it restores dev->irq to the pin-based interrupt number and frees
|
||||
the previously allocated MSIs. The interrupts may subsequently be assigned
|
||||
to another device, so drivers should not cache the value of dev->irq.
|
||||
|
||||
Before calling this function, a device driver must always call free_irq()
|
||||
on any interrupt for which it previously called request_irq().
|
||||
Failure to do so results in a BUG_ON(), leaving the device with
|
||||
MSI enabled and thus leaking its vector.
|
||||
|
||||
4.2.4 pci_msi_vec_count
|
||||
|
||||
int pci_msi_vec_count(struct pci_dev *dev)
|
||||
|
||||
This function could be used to retrieve the number of MSI vectors the
|
||||
device requested (via the Multiple Message Capable register). The MSI
|
||||
specification only allows the returned value to be a power of two,
|
||||
up to a maximum of 2^5 (32).
|
||||
|
||||
If this function returns a negative number, it indicates the device is
|
||||
not capable of sending MSIs.
|
||||
|
||||
If this function returns a positive number, it indicates the maximum
|
||||
number of MSI interrupt vectors that could be allocated.
|
||||
|
||||
4.3 Using MSI-X
|
||||
|
||||
The MSI-X capability is much more flexible than the MSI capability.
|
||||
It supports up to 2048 interrupts, each of which can be controlled
|
||||
independently. To support this flexibility, drivers must use an array of
|
||||
`struct msix_entry':
|
||||
|
||||
struct msix_entry {
|
||||
u16 vector; /* kernel uses to write alloc vector */
|
||||
u16 entry; /* driver uses to specify entry */
|
||||
};
|
||||
|
||||
This allows for the device to use these interrupts in a sparse fashion;
|
||||
for example, it could use interrupts 3 and 1027 and yet allocate only a
|
||||
two-element array. The driver is expected to fill in the 'entry' value
|
||||
in each element of the array to indicate for which entries the kernel
|
||||
should assign interrupts; it is invalid to fill in two entries with the
|
||||
same number.
|
||||
|
||||
4.3.1 pci_enable_msix_range
|
||||
|
||||
int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries,
|
||||
int minvec, int maxvec)
|
||||
|
||||
Calling this function asks the PCI subsystem to allocate any number of
|
||||
MSI-X interrupts within specified range from 'minvec' to 'maxvec'.
|
||||
The 'entries' argument is a pointer to an array of msix_entry structs
|
||||
which should be at least 'maxvec' entries in size.
|
||||
|
||||
On success, the device is switched into MSI-X mode and the function
|
||||
returns the number of MSI-X interrupts that have been successfully
|
||||
allocated. In this case the 'vector' member in entries numbered from
|
||||
0 to the returned value - 1 is populated with the interrupt number;
|
||||
the driver should then call request_irq() for each 'vector' that it
|
||||
decides to use. The device driver is responsible for keeping track of the
|
||||
interrupts assigned to the MSI-X vectors so it can free them again later.
|
||||
Device driver can use the returned number of successfully allocated MSI-X
|
||||
interrupts to further allocate and initialize device resources.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to allocate any more MSI-X interrupts for
|
||||
this device.
|
||||
|
||||
This function, in contrast with pci_enable_msi_range(), does not adjust
|
||||
dev->irq. The device will not generate interrupts for this interrupt
|
||||
number once MSI-X is enabled.
|
||||
|
||||
Device drivers should normally call this function once per device
|
||||
during the initialization phase.
|
||||
|
||||
It is ideal if drivers can cope with a variable number of MSI-X interrupts;
|
||||
there are many reasons why the platform may not be able to provide the
|
||||
exact number that a driver asks for.
|
||||
|
||||
There could be devices that can not operate with just any number of MSI-X
|
||||
interrupts within a range. E.g., an network adapter might need let's say
|
||||
four vectors per each queue it provides. Therefore, a number of MSI-X
|
||||
interrupts allocated should be a multiple of four. In this case interface
|
||||
pci_enable_msix_range() can not be used alone to request MSI-X interrupts
|
||||
(since it can allocate any number within the range, without any notion of
|
||||
the multiple of four) and the device driver should master a custom logic
|
||||
to request the required number of MSI-X interrupts.
|
||||
|
||||
4.3.1.1 Maximum possible number of MSI-X interrupts
|
||||
|
||||
The typical usage of MSI-X interrupts is to allocate as many vectors as
|
||||
possible, likely up to the limit returned by pci_msix_vec_count() function:
|
||||
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
|
||||
{
|
||||
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
1, nvec);
|
||||
}
|
||||
|
||||
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
|
||||
the value of 0 would be meaningless and could result in error.
|
||||
|
||||
Some devices have a minimal limit on number of MSI-X interrupts.
|
||||
In this case the function could look like this:
|
||||
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
|
||||
{
|
||||
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
FOO_DRIVER_MINIMUM_NVEC, nvec);
|
||||
}
|
||||
|
||||
4.3.1.2 Exact number of MSI-X interrupts
|
||||
|
||||
If a driver is unable or unwilling to deal with a variable number of MSI-X
|
||||
interrupts it could request a particular number of interrupts by passing
|
||||
that number to pci_enable_msix_range() function as both 'minvec' and 'maxvec'
|
||||
parameters:
|
||||
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
|
||||
{
|
||||
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
nvec, nvec);
|
||||
}
|
||||
|
||||
Note, unlike pci_enable_msix_exact() function, which could be also used to
|
||||
enable a particular number of MSI-X interrupts, pci_enable_msix_range()
|
||||
returns either a negative errno or 'nvec' (not negative errno or 0 - as
|
||||
pci_enable_msix_exact() does).
|
||||
|
||||
4.3.1.3 Specific requirements to the number of MSI-X interrupts
|
||||
|
||||
As noted above, there could be devices that can not operate with just any
|
||||
number of MSI-X interrupts within a range. E.g., let's assume a device that
|
||||
is only capable sending the number of MSI-X interrupts which is a power of
|
||||
two. A routine that enables MSI-X mode for such device might look like this:
|
||||
|
||||
/*
|
||||
* Assume 'minvec' and 'maxvec' are non-zero
|
||||
*/
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter,
|
||||
int minvec, int maxvec)
|
||||
{
|
||||
int rc;
|
||||
|
||||
minvec = roundup_pow_of_two(minvec);
|
||||
maxvec = rounddown_pow_of_two(maxvec);
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ERANGE;
|
||||
|
||||
retry:
|
||||
rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
maxvec, maxvec);
|
||||
/*
|
||||
* -ENOSPC is the only error code allowed to be analyzed
|
||||
*/
|
||||
if (rc == -ENOSPC) {
|
||||
if (maxvec == 1)
|
||||
return -ENOSPC;
|
||||
|
||||
maxvec /= 2;
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ENOSPC;
|
||||
|
||||
goto retry;
|
||||
}
|
||||
|
||||
return rc;
|
||||
}
|
||||
|
||||
Note how pci_enable_msix_range() return value is analyzed for a fallback -
|
||||
any error code other than -ENOSPC indicates a fatal error and should not
|
||||
be retried.
|
||||
|
||||
4.3.2 pci_enable_msix_exact
|
||||
|
||||
int pci_enable_msix_exact(struct pci_dev *dev,
|
||||
struct msix_entry *entries, int nvec)
|
||||
|
||||
This variation on pci_enable_msix_range() call allows a device driver to
|
||||
request exactly 'nvec' MSI-Xs.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to allocate any more MSI-X interrupts for
|
||||
this device.
|
||||
|
||||
By contrast with pci_enable_msix_range() function, pci_enable_msix_exact()
|
||||
returns zero in case of success, which indicates MSI-X interrupts have been
|
||||
successfully allocated.
|
||||
|
||||
Another version of a routine that enables MSI-X mode for a device with
|
||||
specific requirements described in chapter 4.3.1.3 might look like this:
|
||||
|
||||
/*
|
||||
* Assume 'minvec' and 'maxvec' are non-zero
|
||||
*/
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter,
|
||||
int minvec, int maxvec)
|
||||
{
|
||||
int rc;
|
||||
|
||||
minvec = roundup_pow_of_two(minvec);
|
||||
maxvec = rounddown_pow_of_two(maxvec);
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ERANGE;
|
||||
|
||||
retry:
|
||||
rc = pci_enable_msix_exact(adapter->pdev,
|
||||
adapter->msix_entries, maxvec);
|
||||
|
||||
/*
|
||||
* -ENOSPC is the only error code allowed to be analyzed
|
||||
*/
|
||||
if (rc == -ENOSPC) {
|
||||
if (maxvec == 1)
|
||||
return -ENOSPC;
|
||||
|
||||
maxvec /= 2;
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ENOSPC;
|
||||
|
||||
goto retry;
|
||||
} else if (rc < 0) {
|
||||
return rc;
|
||||
}
|
||||
|
||||
return maxvec;
|
||||
}
|
||||
|
||||
4.3.3 pci_disable_msix
|
||||
|
||||
void pci_disable_msix(struct pci_dev *dev)
|
||||
|
||||
This function should be used to undo the effect of pci_enable_msix_range().
|
||||
It frees the previously allocated MSI-X interrupts. The interrupts may
|
||||
subsequently be assigned to another device, so drivers should not cache
|
||||
the value of the 'vector' elements over a call to pci_disable_msix().
|
||||
|
||||
Before calling this function, a device driver must always call free_irq()
|
||||
on any interrupt for which it previously called request_irq().
|
||||
Failure to do so results in a BUG_ON(), leaving the device with
|
||||
MSI-X enabled and thus leaking its vector.
|
||||
|
||||
4.3.3 The MSI-X Table
|
||||
|
||||
The MSI-X capability specifies a BAR and offset within that BAR for the
|
||||
MSI-X Table. This address is mapped by the PCI subsystem, and should not
|
||||
be accessed directly by the device driver. If the driver wishes to
|
||||
mask or unmask an interrupt, it should call disable_irq() / enable_irq().
|
||||
|
||||
4.3.4 pci_msix_vec_count
|
||||
|
||||
int pci_msix_vec_count(struct pci_dev *dev)
|
||||
|
||||
This function could be used to retrieve number of entries in the device
|
||||
MSI-X table.
|
||||
|
||||
If this function returns a negative number, it indicates the device is
|
||||
not capable of sending MSI-Xs.
|
||||
|
||||
If this function returns a positive number, it indicates the maximum
|
||||
number of MSI-X interrupt vectors that could be allocated.
|
||||
|
||||
4.4 Handling devices implementing both MSI and MSI-X capabilities
|
||||
|
||||
If a device implements both MSI and MSI-X capabilities, it can
|
||||
run in either MSI mode or MSI-X mode, but not both simultaneously.
|
||||
This is a requirement of the PCI spec, and it is enforced by the
|
||||
PCI layer. Calling pci_enable_msi_range() when MSI-X is already
|
||||
enabled or pci_enable_msix_range() when MSI is already enabled
|
||||
results in an error. If a device driver wishes to switch between MSI
|
||||
and MSI-X at runtime, it must first quiesce the device, then switch
|
||||
it back to pin-interrupt mode, before calling pci_enable_msi_range()
|
||||
or pci_enable_msix_range() and resuming operation. This is not expected
|
||||
to be a common operation but may be useful for debugging or testing
|
||||
during development.
|
||||
|
||||
4.5 Considerations when using MSIs
|
||||
|
||||
4.5.1 Choosing between MSI-X and MSI
|
||||
|
||||
If your device supports both MSI-X and MSI capabilities, you should use
|
||||
the MSI-X facilities in preference to the MSI facilities. As mentioned
|
||||
above, MSI-X supports any number of interrupts between 1 and 2048.
|
||||
In contrast, MSI is restricted to a maximum of 32 interrupts (and
|
||||
must be a power of two). In addition, the MSI interrupt vectors must
|
||||
be allocated consecutively, so the system might not be able to allocate
|
||||
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
|
||||
interrupts must all be targeted at the same set of CPUs whereas MSI-X
|
||||
interrupts can all be targeted at different CPUs.
|
||||
|
||||
4.5.2 Spinlocks
|
||||
4.4.1 Spinlocks
|
||||
|
||||
Most device drivers have a per-device spinlock which is taken in the
|
||||
interrupt handler. With pin-based interrupts or a single MSI, it is not
|
||||
|
|
@ -505,7 +194,7 @@ acquire the spinlock. Such deadlocks can be avoided by using
|
|||
spin_lock_irqsave() or spin_lock_irq() which disable local interrupts
|
||||
and acquire the lock (see Documentation/DocBook/kernel-locking).
|
||||
|
||||
4.6 How to tell whether MSI/MSI-X is enabled on a device
|
||||
4.5 How to tell whether MSI/MSI-X is enabled on a device
|
||||
|
||||
Using 'lspci -v' (as root) may show some devices with "MSI", "Message
|
||||
Signalled Interrupts" or "MSI-X" capabilities. Each of these capabilities
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ Required properties:
|
|||
- "ti,ina220" for ina220
|
||||
- "ti,ina226" for ina226
|
||||
- "ti,ina230" for ina230
|
||||
- "ti,ina231" for ina231
|
||||
- reg: I2C address
|
||||
|
||||
Optional properties:
|
||||
|
|
|
|||
|
|
@ -44,8 +44,8 @@ Required properties:
|
|||
- our-claim-gpio: The GPIO that we use to claim the bus.
|
||||
- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
|
||||
Note that some implementations may only support a single other master.
|
||||
- Standard I2C mux properties. See mux.txt in this directory.
|
||||
- Single I2C child bus node at reg 0. See mux.txt in this directory.
|
||||
- Standard I2C mux properties. See i2c-mux.txt in this directory.
|
||||
- Single I2C child bus node at reg 0. See i2c-mux.txt in this directory.
|
||||
|
||||
Optional properties:
|
||||
- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
|
||||
|
|
|
|||
|
|
@ -27,7 +27,8 @@ Required properties:
|
|||
- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
|
||||
parents.
|
||||
|
||||
Furthermore, I2C mux properties and child nodes. See mux.txt in this directory.
|
||||
Furthermore, I2C mux properties and child nodes. See i2c-mux.txt in this
|
||||
directory.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ Required properties:
|
|||
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
|
||||
port is connected to.
|
||||
- mux-gpios: list of gpios used to control the muxer
|
||||
* Standard I2C mux properties. See mux.txt in this directory.
|
||||
* I2C child bus nodes. See mux.txt in this directory.
|
||||
* Standard I2C mux properties. See i2c-mux.txt in this directory.
|
||||
* I2C child bus nodes. See i2c-mux.txt in this directory.
|
||||
|
||||
Optional properties:
|
||||
- idle-state: value to set the muxer to when idle. When no value is
|
||||
|
|
@ -33,7 +33,7 @@ For each i2c child node, an I2C child bus will be created. They will
|
|||
be numbered based on their order in the device tree.
|
||||
|
||||
Whenever an access is made to a device on a child bus, the value set
|
||||
in the revelant node's reg property will be output using the list of
|
||||
in the relevant node's reg property will be output using the list of
|
||||
GPIOs, the first in the list holding the least-significant value.
|
||||
|
||||
If an idle state is defined, using the idle-state (optional) property,
|
||||
|
|
|
|||
|
|
@ -28,9 +28,9 @@ Also required are:
|
|||
* Standard pinctrl properties that specify the pin mux state for each child
|
||||
bus. See ../pinctrl/pinctrl-bindings.txt.
|
||||
|
||||
* Standard I2C mux properties. See mux.txt in this directory.
|
||||
* Standard I2C mux properties. See i2c-mux.txt in this directory.
|
||||
|
||||
* I2C child bus nodes. See mux.txt in this directory.
|
||||
* I2C child bus nodes. See i2c-mux.txt in this directory.
|
||||
|
||||
For each named state defined in the pinctrl-names property, an I2C child bus
|
||||
will be created. I2C child bus numbers are assigned based on the index into
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ Required properties:
|
|||
- compatible: i2c-mux-reg
|
||||
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
|
||||
port is connected to.
|
||||
* Standard I2C mux properties. See mux.txt in this directory.
|
||||
* I2C child bus nodes. See mux.txt in this directory.
|
||||
* Standard I2C mux properties. See i2c-mux.txt in this directory.
|
||||
* I2C child bus nodes. See i2c-mux.txt in this directory.
|
||||
|
||||
Optional properties:
|
||||
- reg: this pair of <offset size> specifies the register to control the mux.
|
||||
|
|
@ -24,7 +24,7 @@ Optional properties:
|
|||
given, it defaults to the last value used.
|
||||
|
||||
Whenever an access is made to a device on a child bus, the value set
|
||||
in the revelant node's reg property will be output to the register.
|
||||
in the relevant node's reg property will be output to the register.
|
||||
|
||||
If an idle state is defined, using the idle-state (optional) property,
|
||||
whenever an access is not being made to a device on a child bus, the
|
||||
|
|
|
|||
|
|
@ -13,10 +13,10 @@ Optional properties:
|
|||
initialization. This is an array of 28 values(u8).
|
||||
|
||||
- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
|
||||
firmware will use the pin to wakeup host system.
|
||||
firmware will use the pin to wakeup host system (u16).
|
||||
- marvell,wakeup-gap-ms: wakeup gap represents wakeup latency of the host
|
||||
platform. The value will be configured to firmware. This
|
||||
is needed to work chip's sleep feature as expected.
|
||||
is needed to work chip's sleep feature as expected (u16).
|
||||
- interrupt-parent: phandle of the parent interrupt controller
|
||||
- interrupts : interrupt pin number to the cpu. Driver will request an irq based
|
||||
on this interrupt number. During system suspend, the irq will be
|
||||
|
|
@ -50,7 +50,7 @@ calibration data is also available in below example.
|
|||
0x37 0x01 0x1c 0x00 0xff 0xff 0xff 0xff 0x01 0x7f 0x04 0x02
|
||||
0x00 0x00 0xba 0xce 0xc0 0xc6 0x2d 0x00 0x00 0x00 0x00 0x00
|
||||
0x00 0x00 0xf0 0x00>;
|
||||
marvell,wakeup-pin = <0x0d>;
|
||||
marvell,wakeup-gap-ms = <0x64>;
|
||||
marvell,wakeup-pin = /bits/ 16 <0x0d>;
|
||||
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -255,6 +255,7 @@ synology Synology, Inc.
|
|||
SUNW Sun Microsystems, Inc
|
||||
tbs TBS Technologies
|
||||
tcl Toby Churchill Ltd.
|
||||
technexion TechNexion
|
||||
technologic Technologic Systems
|
||||
thine THine Electronics, Inc.
|
||||
ti Texas Instruments
|
||||
|
|
@ -269,6 +270,7 @@ tronsmart Tronsmart
|
|||
truly Truly Semiconductors Limited
|
||||
tyan Tyan Computer Corporation
|
||||
upisemi uPI Semiconductor Corp.
|
||||
uniwest United Western Technologies Corp (UniWest)
|
||||
urt United Radiant Technology Corporation
|
||||
usi Universal Scientific Industrial Co., Ltd.
|
||||
v3 V3 Semiconductor
|
||||
|
|
|
|||
|
|
@ -74,8 +74,8 @@ blink_set() function (see <linux/leds.h>). To set an LED to blinking,
|
|||
however, it is better to use the API function led_blink_set(), as it
|
||||
will check and implement software fallback if necessary.
|
||||
|
||||
To turn off blinking again, use the API function led_brightness_set()
|
||||
as that will not just set the LED brightness but also stop any software
|
||||
To turn off blinking, use the API function led_brightness_set()
|
||||
with brightness value LED_OFF, which should stop any software
|
||||
timers that may have been required for blinking.
|
||||
|
||||
The blink_set() function should choose a user friendly blinking value
|
||||
|
|
|
|||
|
|
@ -263,19 +263,23 @@ scmd->allowed.
|
|||
|
||||
3. scmd recovered
|
||||
ACTION: scsi_eh_finish_cmd() is invoked to EH-finish scmd
|
||||
- shost->host_failed--
|
||||
- clear scmd->eh_eflags
|
||||
- scsi_setup_cmd_retry()
|
||||
- move from local eh_work_q to local eh_done_q
|
||||
LOCKING: none
|
||||
CONCURRENCY: at most one thread per separate eh_work_q to
|
||||
keep queue manipulation lockless
|
||||
|
||||
4. EH completes
|
||||
ACTION: scsi_eh_flush_done_q() retries scmds or notifies upper
|
||||
layer of failure.
|
||||
layer of failure. May be called concurrently but must have
|
||||
a no more than one thread per separate eh_work_q to
|
||||
manipulate the queue locklessly
|
||||
- scmd is removed from eh_done_q and scmd->eh_entry is cleared
|
||||
- if retry is necessary, scmd is requeued using
|
||||
scsi_queue_insert()
|
||||
- otherwise, scsi_finish_command() is invoked for scmd
|
||||
- zero shost->host_failed
|
||||
LOCKING: queue or finish function performs appropriate locking
|
||||
|
||||
|
||||
|
|
|
|||
81
MAINTAINERS
81
MAINTAINERS
|
|
@ -595,6 +595,10 @@ S: Odd Fixes
|
|||
L: linux-alpha@vger.kernel.org
|
||||
F: arch/alpha/
|
||||
|
||||
ALPS PS/2 TOUCHPAD DRIVER
|
||||
R: Pali Rohár <pali.rohar@gmail.com>
|
||||
F: drivers/input/mouse/alps.*
|
||||
|
||||
ALTERA MAILBOX DRIVER
|
||||
M: Ley Foon Tan <lftan@altera.com>
|
||||
L: nios2-dev@lists.rocketboards.org (moderated for non-subscribers)
|
||||
|
|
@ -1159,6 +1163,7 @@ F: arch/arm/mach-footbridge/
|
|||
ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
|
||||
M: Shawn Guo <shawnguo@kernel.org>
|
||||
M: Sascha Hauer <kernel@pengutronix.de>
|
||||
R: Fabio Estevam <fabio.estevam@nxp.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
|
||||
|
|
@ -2242,7 +2247,8 @@ F: include/net/ax25.h
|
|||
F: net/ax25/
|
||||
|
||||
AZ6007 DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -2709,7 +2715,8 @@ F: Documentation/filesystems/btrfs.txt
|
|||
F: fs/btrfs/
|
||||
|
||||
BTTV VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -2773,9 +2780,9 @@ F: include/net/caif/
|
|||
F: net/caif/
|
||||
|
||||
CALGARY x86-64 IOMMU
|
||||
M: Muli Ben-Yehuda <muli@il.ibm.com>
|
||||
M: "Jon D. Mason" <jdmason@kudzu.us>
|
||||
L: discuss@x86-64.org
|
||||
M: Muli Ben-Yehuda <mulix@mulix.org>
|
||||
M: Jon Mason <jdmason@kudzu.us>
|
||||
L: iommu@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
F: arch/x86/kernel/pci-calgary_64.c
|
||||
F: arch/x86/kernel/tce_64.c
|
||||
|
|
@ -3086,6 +3093,7 @@ M: Stephen Boyd <sboyd@codeaurora.org>
|
|||
L: linux-clk@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/clock/
|
||||
F: drivers/clk/
|
||||
X: drivers/clk/clkdev.c
|
||||
F: include/linux/clk-pr*
|
||||
|
|
@ -3343,7 +3351,8 @@ S: Maintained
|
|||
F: drivers/media/dvb-frontends/cx24120*
|
||||
|
||||
CX88 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -3773,6 +3782,7 @@ Q: https://patchwork.kernel.org/project/linux-dmaengine/list/
|
|||
S: Maintained
|
||||
F: drivers/dma/
|
||||
F: include/linux/dmaengine.h
|
||||
F: Documentation/devicetree/bindings/dma/
|
||||
F: Documentation/dmaengine/
|
||||
T: git git://git.infradead.org/users/vkoul/slave-dma.git
|
||||
|
||||
|
|
@ -4290,7 +4300,8 @@ F: fs/ecryptfs/
|
|||
EDAC-CORE
|
||||
M: Doug Thompson <dougthompson@xmission.com>
|
||||
M: Borislav Petkov <bp@alien8.de>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git for-next
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac.git linux_next
|
||||
|
|
@ -4335,7 +4346,8 @@ S: Maintained
|
|||
F: drivers/edac/e7xxx_edac.c
|
||||
|
||||
EDAC-GHES
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/edac/ghes_edac.c
|
||||
|
|
@ -4359,19 +4371,22 @@ S: Maintained
|
|||
F: drivers/edac/i5000_edac.c
|
||||
|
||||
EDAC-I5400
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/edac/i5400_edac.c
|
||||
|
||||
EDAC-I7300
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/edac/i7300_edac.c
|
||||
|
||||
EDAC-I7CORE
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/edac/i7core_edac.c
|
||||
|
|
@ -4408,7 +4423,8 @@ S: Maintained
|
|||
F: drivers/edac/r82600_edac.c
|
||||
|
||||
EDAC-SBRIDGE
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/edac/sb_edac.c
|
||||
|
|
@ -4467,7 +4483,8 @@ S: Maintained
|
|||
F: drivers/net/ethernet/ibm/ehea/
|
||||
|
||||
EM28XX VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -6486,6 +6503,7 @@ F: include/uapi/linux/sunrpc/
|
|||
|
||||
KERNEL SELFTEST FRAMEWORK
|
||||
M: Shuah Khan <shuahkh@osg.samsung.com>
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
L: linux-kselftest@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/shuah/linux-kselftest
|
||||
S: Maintained
|
||||
|
|
@ -7357,7 +7375,8 @@ S: Supported
|
|||
F: drivers/media/pci/netup_unidvb/*
|
||||
|
||||
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
P: LinuxTV.org Project
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
|
@ -7405,7 +7424,7 @@ F: drivers/scsi/megaraid.*
|
|||
F: drivers/scsi/megaraid/
|
||||
|
||||
MELLANOX ETHERNET DRIVER (mlx4_en)
|
||||
M: Eugenia Emantayev <eugenia@mellanox.com>
|
||||
M: Tariq Toukan <tariqt@mellanox.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
|
|
@ -8008,6 +8027,7 @@ Q: http://patchwork.kernel.org/project/linux-wireless/list/
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/wireless/
|
||||
F: drivers/net/wireless/
|
||||
|
||||
NETXEN (1/10) GbE SUPPORT
|
||||
|
|
@ -8405,10 +8425,9 @@ F: drivers/i2c/busses/i2c-ocores.c
|
|||
OPEN FIRMWARE AND FLATTENED DEVICE TREE
|
||||
M: Rob Herring <robh+dt@kernel.org>
|
||||
M: Frank Rowand <frowand.list@gmail.com>
|
||||
M: Grant Likely <grant.likely@linaro.org>
|
||||
L: devicetree@vger.kernel.org
|
||||
W: http://www.devicetree.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
|
||||
S: Maintained
|
||||
F: drivers/of/
|
||||
F: include/linux/of*.h
|
||||
|
|
@ -8416,12 +8435,10 @@ F: scripts/dtc/
|
|||
|
||||
OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
|
||||
M: Rob Herring <robh+dt@kernel.org>
|
||||
M: Pawel Moll <pawel.moll@arm.com>
|
||||
M: Mark Rutland <mark.rutland@arm.com>
|
||||
M: Ian Campbell <ijc+devicetree@hellion.org.uk>
|
||||
M: Kumar Gala <galak@codeaurora.org>
|
||||
L: devicetree@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
|
||||
Q: http://patchwork.ozlabs.org/project/devicetree-bindings/list/
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/
|
||||
F: arch/*/boot/dts/
|
||||
|
|
@ -8963,6 +8980,7 @@ L: linux-gpio@vger.kernel.org
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pinctrl/
|
||||
F: Documentation/pinctrl.txt
|
||||
F: drivers/pinctrl/
|
||||
F: include/linux/pinctrl/
|
||||
|
||||
|
|
@ -9870,7 +9888,8 @@ S: Odd Fixes
|
|||
F: drivers/media/i2c/saa6588*
|
||||
|
||||
SAA7134 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -10389,7 +10408,8 @@ S: Maintained
|
|||
F: drivers/media/radio/si4713/radio-usb-si4713.c
|
||||
|
||||
SIANO DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -11155,7 +11175,8 @@ S: Maintained
|
|||
F: drivers/media/i2c/tda9840*
|
||||
|
||||
TEA5761 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -11163,7 +11184,8 @@ S: Odd fixes
|
|||
F: drivers/media/tuners/tea5761.*
|
||||
|
||||
TEA5767 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -11550,7 +11572,8 @@ F: include/linux/shmem_fs.h
|
|||
F: mm/shmem.c
|
||||
|
||||
TM6000 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -11904,7 +11927,8 @@ F: drivers/usb/common/usb-otg-fsm.c
|
|||
|
||||
USB OVER IP DRIVER
|
||||
M: Valentina Manea <valentina.manea.m@gmail.com>
|
||||
M: Shuah Khan <shuah.kh@samsung.com>
|
||||
M: Shuah Khan <shuahkh@osg.samsung.com>
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/usb/usbip_protocol.txt
|
||||
|
|
@ -11975,6 +11999,7 @@ L: linux-usb@vger.kernel.org
|
|||
W: http://www.linux-usb.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/usb/
|
||||
F: Documentation/usb/
|
||||
F: drivers/usb/
|
||||
F: include/linux/usb.h
|
||||
|
|
@ -12148,6 +12173,7 @@ VIRTIO CORE, NET AND BLOCK DRIVERS
|
|||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: virtualization@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/virtio/
|
||||
F: drivers/virtio/
|
||||
F: tools/virtio/
|
||||
F: drivers/net/virtio_net.c
|
||||
|
|
@ -12536,7 +12562,8 @@ S: Maintained
|
|||
F: arch/x86/entry/vdso/
|
||||
|
||||
XC2028/3028 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
|
|||
4
Makefile
4
Makefile
|
|
@ -1,7 +1,7 @@
|
|||
VERSION = 4
|
||||
PATCHLEVEL = 7
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc2
|
||||
EXTRAVERSION = -rc6
|
||||
NAME = Psychotic Stoned Sheep
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -363,11 +363,13 @@ CHECK = sparse
|
|||
|
||||
CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
|
||||
-Wbitwise -Wno-return-void $(CF)
|
||||
NOSTDINC_FLAGS =
|
||||
CFLAGS_MODULE =
|
||||
AFLAGS_MODULE =
|
||||
LDFLAGS_MODULE =
|
||||
CFLAGS_KERNEL =
|
||||
AFLAGS_KERNEL =
|
||||
LDFLAGS_vmlinux =
|
||||
CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
|
||||
CFLAGS_KCOV = -fsanitize-coverage=trace-pc
|
||||
|
||||
|
|
|
|||
|
|
@ -226,8 +226,8 @@ config ARCH_INIT_TASK
|
|||
config ARCH_TASK_STRUCT_ALLOCATOR
|
||||
bool
|
||||
|
||||
# Select if arch has its private alloc_thread_info() function
|
||||
config ARCH_THREAD_INFO_ALLOCATOR
|
||||
# Select if arch has its private alloc_thread_stack() function
|
||||
config ARCH_THREAD_STACK_ALLOCATOR
|
||||
bool
|
||||
|
||||
# Select if arch wants to size task_struct dynamically via arch_task_struct_size:
|
||||
|
|
@ -606,6 +606,9 @@ config HAVE_ARCH_HASH
|
|||
file which provides platform-specific implementations of some
|
||||
functions in <linux/hash.h> or fs/namei.c.
|
||||
|
||||
config ISA_BUS_API
|
||||
def_bool ISA
|
||||
|
||||
#
|
||||
# ABI hall of shame
|
||||
#
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ pgd_free(struct mm_struct *mm, pgd_t *pgd)
|
|||
static inline pmd_t *
|
||||
pmd_alloc_one(struct mm_struct *mm, unsigned long address)
|
||||
{
|
||||
pmd_t *ret = (pmd_t *)__get_free_page(GFP_KERNEL|__GFP_REPEAT|__GFP_ZERO);
|
||||
pmd_t *ret = (pmd_t *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
|
||||
return ret;
|
||||
}
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ pmd_free(struct mm_struct *mm, pmd_t *pmd)
|
|||
static inline pte_t *
|
||||
pte_alloc_one_kernel(struct mm_struct *mm, unsigned long address)
|
||||
{
|
||||
pte_t *pte = (pte_t *)__get_free_page(GFP_KERNEL|__GFP_REPEAT|__GFP_ZERO);
|
||||
pte_t *pte = (pte_t *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
|
||||
return pte;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ config RWSEM_GENERIC_SPINLOCK
|
|||
def_bool y
|
||||
|
||||
config ARCH_DISCONTIGMEM_ENABLE
|
||||
def_bool y
|
||||
def_bool n
|
||||
|
||||
config ARCH_FLATMEM_ENABLE
|
||||
def_bool y
|
||||
|
|
@ -186,9 +186,6 @@ if SMP
|
|||
config ARC_HAS_COH_CACHES
|
||||
def_bool n
|
||||
|
||||
config ARC_HAS_REENTRANT_IRQ_LV2
|
||||
def_bool n
|
||||
|
||||
config ARC_MCIP
|
||||
bool "ARConnect Multicore IP (MCIP) Support "
|
||||
depends on ISA_ARCV2
|
||||
|
|
@ -366,25 +363,10 @@ config NODES_SHIFT
|
|||
if ISA_ARCOMPACT
|
||||
|
||||
config ARC_COMPACT_IRQ_LEVELS
|
||||
bool "ARCompact IRQ Priorities: High(2)/Low(1)"
|
||||
bool "Setup Timer IRQ as high Priority"
|
||||
default n
|
||||
# Timer HAS to be high priority, for any other high priority config
|
||||
select ARC_IRQ3_LV2
|
||||
# if SMP, LV2 enabled ONLY if ARC implementation has LV2 re-entrancy
|
||||
depends on !SMP || ARC_HAS_REENTRANT_IRQ_LV2
|
||||
|
||||
if ARC_COMPACT_IRQ_LEVELS
|
||||
|
||||
config ARC_IRQ3_LV2
|
||||
bool
|
||||
|
||||
config ARC_IRQ5_LV2
|
||||
bool
|
||||
|
||||
config ARC_IRQ6_LV2
|
||||
bool
|
||||
|
||||
endif #ARC_COMPACT_IRQ_LEVELS
|
||||
depends on !SMP
|
||||
|
||||
config ARC_FPU_SAVE_RESTORE
|
||||
bool "Enable FPU state persistence across context switch"
|
||||
|
|
@ -407,11 +389,6 @@ config ARC_HAS_LLSC
|
|||
default y
|
||||
depends on !ARC_CANT_LLSC
|
||||
|
||||
config ARC_STAR_9000923308
|
||||
bool "Workaround for llock/scond livelock"
|
||||
default n
|
||||
depends on ISA_ARCV2 && SMP && ARC_HAS_LLSC
|
||||
|
||||
config ARC_HAS_SWAPE
|
||||
bool "Insn: SWAPE (endian-swap)"
|
||||
default y
|
||||
|
|
@ -471,7 +448,7 @@ config LINUX_LINK_BASE
|
|||
|
||||
config HIGHMEM
|
||||
bool "High Memory Support"
|
||||
select DISCONTIGMEM
|
||||
select ARCH_DISCONTIGMEM_ENABLE
|
||||
help
|
||||
With ARC 2G:2G address split, only upper 2G is directly addressable by
|
||||
kernel. Enable this to potentially allow access to rest of 2G and PAE
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue