Char/Misc driver merge for 3.8-rc1

Here is the "big" char/misc driver patches for 3.8-rc1.  I'm starting to
 put random driver subsystems that I had previously sent you through the
 driver-core tree in this tree, as it makes more sense to do so.
 
 Nothing major here, the various __dev* removals, some mei driver
 updates, and other random driver-specific things from the different
 maintainers and developers.
 
 Note, some MFD drivers got added through this tree, and they are also
 coming in through the "real" MFD tree as well, due to some major
 mis-communication between me and the different developers.  If you have
 any merge conflicts, take the ones from the MFD tree, not these ones,
 sorry about that.
 
 All of this has been in linux-next for a while.
 
 Signed-off-by: Greg Kroah-Hartman <[email protected]>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iEYEABECAAYFAlDHj7AACgkQMUfUDdst+ym7pQCgxhFDGQRJimG+Ddag+ghfLhQh
 Ql0AoJsWVFvQjb7q1NO7OvOABaxjEJdu
 =na5b
 -----END PGP SIGNATURE-----

Merge tag 'char-misc-3.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

Pull Char/Misc driver merge from Greg Kroah-Hartman:
 "Here is the "big" char/misc driver patches for 3.8-rc1.  I'm starting
  to put random driver subsystems that I had previously sent you through
  the driver-core tree in this tree, as it makes more sense to do so.

  Nothing major here, the various __dev* removals, some mei driver
  updates, and other random driver-specific things from the different
  maintainers and developers.

  Note, some MFD drivers got added through this tree, and they are also
  coming in through the "real" MFD tree as well, due to some major
  mis-communication between me and the different developers.  If you
  have any merge conflicts, take the ones from the MFD tree, not these
  ones, sorry about that.

  All of this has been in linux-next for a while.

  Signed-off-by: Greg Kroah-Hartman <[email protected]>"

Fix up trivial conflict in drivers/mmc/host/Kconfig due to new drivers
having been added (both at the end, as usual..)

* tag 'char-misc-3.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (84 commits)
  MAINTAINERS: remove drivers/staging/hv/
  misc/st_kim: Free resources in the error path of probe()
  drivers/char: for hpet, add count checking, and ~0UL instead of -1
  w1-gpio: Simplify & get rid of defines
  w1-gpio: Pinctrl-fy
  extcon: remove use of __devexit_p
  extcon: remove use of __devinit
  extcon: remove use of __devexit
  drivers: uio: Only allocate new private data when probing device tree node
  drivers: uio_dmem_genirq: Allow partial success when opening device
  drivers: uio_dmem_genirq: Don't use DMA_ERROR_CODE to indicate unmapped regions
  drivers: uio_dmem_genirq: Don't mix address spaces for dynamic region vaddr
  uio: remove use of __devexit
  uio: remove use of __devinitdata
  uio: remove use of __devinit
  uio: remove use of __devexit_p
  char: remove use of __devexit
  char: remove use of __devinitconst
  char: remove use of __devinitdata
  char: remove use of __devinit
  ...
This commit is contained in:
Linus Torvalds 2012-12-11 13:56:38 -08:00
commit 6a5971d8fe
135 changed files with 8217 additions and 1867 deletions

View file

@ -719,6 +719,62 @@ framework to set up sysfs files for this region. Simply leave it alone.
</para>
</sect1>
<sect1 id="using uio_dmem_genirq">
<title>Using uio_dmem_genirq for platform devices</title>
<para>
In addition to statically allocated memory ranges, they may also be
a desire to use dynamically allocated regions in a user space driver.
In particular, being able to access memory made available through the
dma-mapping API, may be particularly useful. The
<varname>uio_dmem_genirq</varname> driver provides a way to accomplish
this.
</para>
<para>
This driver is used in a similar manner to the
<varname>"uio_pdrv_genirq"</varname> driver with respect to interrupt
configuration and handling.
</para>
<para>
Set the <varname>.name</varname> element of
<varname>struct platform_device</varname> to
<varname>"uio_dmem_genirq"</varname> to use this driver.
</para>
<para>
When using this driver, fill in the <varname>.platform_data</varname>
element of <varname>struct platform_device</varname>, which is of type
<varname>struct uio_dmem_genirq_pdata</varname> and which contains the
following elements:
</para>
<itemizedlist>
<listitem><varname>struct uio_info uioinfo</varname>: The same
structure used as the <varname>uio_pdrv_genirq</varname> platform
data</listitem>
<listitem><varname>unsigned int *dynamic_region_sizes</varname>:
Pointer to list of sizes of dynamic memory regions to be mapped into
user space.
</listitem>
<listitem><varname>unsigned int num_dynamic_regions</varname>:
Number of elements in <varname>dynamic_region_sizes</varname> array.
</listitem>
</itemizedlist>
<para>
The dynamic regions defined in the platform data will be appended to
the <varname> mem[] </varname> array after the platform device
resources, which implies that the total number of static and dynamic
memory regions cannot exceed <varname>MAX_UIO_MAPS</varname>.
</para>
<para>
The dynamic memory regions will be allocated when the UIO device file,
<varname>/dev/uioX</varname> is opened.
Simiar to static memory resources, the memory region information for
dynamic regions is then visible via sysfs at
<varname>/sys/class/uio/uioX/maps/mapY/*</varname>.
The dynmaic memory regions will be freed when the UIO device file is
closed. When no processes are holding the device file open, the address
returned to userspace is ~0.
</para>
</sect1>
</chapter>
<chapter id="userspace_driver" xreflabel="Writing a driver in user space">