Rafael Barbalho [Wed, 21 Aug 2013 16:10:51 +0000 (17:10 +0100)]
drm/i915: Cleaning up the relocate entry function
As the relocate entry function was getting a bit too big I've moved
the code that used to use either the cpu or the gtt to for the
relocation into two separate functions.
Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gerhard Sittig [Tue, 6 Aug 2013 20:43:43 +0000 (22:43 +0200)]
USB: fsl-mph-dr-of: cleanup clock API use
use devm_get_clk() for automatic put upon device close, check for and
propagate errors when enabling clocks, must prepare clocks before they
can get enabled, unprepare after disable
Signed-off-by: Gerhard Sittig <gsi@denx.de> Signed-off-by: Anatolij Gustschin <agust@denx.de>
Jussi Kivilinna [Tue, 6 Aug 2013 12:03:29 +0000 (15:03 +0300)]
mtd: remove alauda driver
The driver has very low utility. Devices in question are limited to
about 400kB/s and the only known user (me) discarded the hardware
several years back.
Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Gerhard Sittig [Tue, 6 Aug 2013 20:43:42 +0000 (22:43 +0200)]
serial: mpc512x: cleanup clock API use
cleanup the clock API use of the UART driver which is shared among the
MPC512x and the MPC5200 platforms
- get, prepare, and enable the MCLK during port allocation; disable,
unprepare and put the MCLK upon port release; hold a reference to the
clock over the period of use; check for and propagate enable errors
- fix a buffer overflow for clock names with two digit PSC index numbers
- stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
switch to a fixed string later after device tree based clock lookup
will have become available
to achieve support for MPC512x which is neutral to MPC5200, the
modification was done as follows
- introduce "clock alloc" and "clock release" routines in addition to
the previous "clock enable/disable" routine in the psc_ops struct
- make the clock allocation a part of the port request (resource
allocation), and make clock release a part of the port release, such
that essential resources get allocated early
- just enable/disable the clock from within the .clock() callback
without any allocation or preparation as the former implementation
did, since this routine is called from within the startup and shutdown
callbacks
- all of the above remains a NOP for the MPC5200 platform (no callbacks
are provided on that platform)
- implementation note: the clock gets enabled upon allocation already
just in case the clock is not only required for bitrate generation but
for register access as well
David S. Miller [Wed, 21 Aug 2013 19:21:50 +0000 (12:21 -0700)]
Merge branch 'tuntap'
Pavel Emelyanov says:
====================
tun: Some bits required for tun's checkpoint-restore (v2)
After taking a closer look on tun checkpoint-restore I've found several
issues with the tun's API that make it impossible to dump and restore
the state of tun device and attached tun-files.
The proposed API changes are all about extending the existing ioctl-based
stuff. Patches fit today's net-next.
This v2 has David's comments about patch #1 fixed. All the rest is the same.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Pavel Emelyanov [Wed, 21 Aug 2013 10:32:39 +0000 (14:32 +0400)]
tun: Get skfilter layout
The only thing we may have from tun device is the fprog, whic contains
the number of filter elements and a pointer to (user-space) memory
where the elements are. The program itself may not be available if the
device is persistent and detached.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com> Signed-off-by: David S. Miller <davem@davemloft.net>
we most likely receive the -EFAULT error, since tun_attach() would
try to connect the filter back. But (!) if we provide a filter at
address &my_filter, then tun0 will be created and the "new" filter
would be attached, but application may not know about that.
This may create certain problems to anyone using tun-s, but it's
critical problem for c/r -- if we meet a persistent tun device
with a filter in mind, we will not be able to attach to it to dump
its state (flags, owner, address, vnethdr size, etc.).
The proposal is to allow to attach to tun device (with TUNSETIFF)
w/o attaching the filter to the tun-file's socket. After this
attach app may e.g clean the device by dropping the filter, it
doesn't want to have one, or (in case of c/r) get information
about the device with tun ioctls.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Pavel Emelyanov [Wed, 21 Aug 2013 10:31:38 +0000 (14:31 +0400)]
tun: Add ability to create tun device with given index
Tun devices cannot be created with ifidex user wants, but it's
required by checkpoint-restore project.
Long time ago such ability was implemented for rtnl_ops-based
interface for creating links (9c7dafbf net: Allow to create links
with given ifindex), but the only API for creating and managing
tuntap devices is ioctl-based and is evolving with adding new ones
(cde8b15f tuntap: add ioctl to attach or detach a file form tuntap
device).
Following that trend, here's how a new ioctl that sets the ifindex
for device, that _will_ be created by TUNSETIFF ioctl looks like.
So those who want a tuntap device with the ifindex N, should open
the tun device, call ioctl(fd, TUNSETIFINDEX, &N), then call TUNSETIFF.
If the index N is busy, then the register_netdev will find this out
and the ioctl would be failed with -EBUSY.
If setifindex is not called, then it will be generated as before.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / karo-tx-linux.git / log