No need to duplicate them in both callers; make it return
ERR_PTR(-ENOMEM) on allocation failure instead of NULL and
it'll be able to report rpc_lookup_cred() failures just
fine. Callers are much happier that way...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
SMSC generation 4 LAN chips integrate an IEEE 802.3 ethernet physical layer.
The ethernet driver for this family of devices needs to access the SMSC PHY
registers and bit-fields.
So, this patch moves these constants to a place where it can be used for both
the PHY and LAN drivers.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 1e39f384bb ("evm: fix build problems") makes the stub version
of security_old_inode_init_security() return 0 when CONFIG_SECURITY is
not set.
But that makes callers such as reiserfs_security_init() assume that
security_old_inode_init_security() has set name, value, and len
arguments properly - but security_old_inode_init_security() left them
uninitialized which then results in interesting failures.
Revert security_old_inode_init_security() to the old behavior of
returning EOPNOTSUPP since both callers (reiserfs and ocfs2) handle this
just fine.
[ Also fixed the S_PRIVATE(inode) case of the actual non-stub
security_old_inode_init_security() function to return EOPNOTSUPP
for the same reason, as pointed out by Mimi Zohar.
It got incorrectly changed to match the new function in commit
fb88c2b6cb: "evm: fix security/security_old_init_security return
code". - Linus ]
Reported-by: Jorge Bastos <mysql.jorge@decimal.pt>
Acked-by: James Morris <jmorris@namei.org>
Acked-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch allows consumers to forcibly disable multiple regulator
clients in a single API call.
Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
These registers are automatically incremented by the hardware during
transform feedback to track where the next streamed vertex output
should go. Unlike the previous generation, which had a packet for
setting the corresponding registers to a defined value, gen7 only has
MI_LOAD_REGISTER_IMM to do so. That's a secure packet (since it loads
an arbitrary register), so we need to do it from the kernel, and it
needs to be settable atomically with the batchbuffer execution so that
two clients doing transform feedback don't stomp on each others'
state.
Instead of building a more complicated interface involcing setting the
registers to a specific value, just set them to 0 when asked and
userland can tweak its pointers accordingly.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
v2: remove unnecessary mutex acquire/release around reg accesses
v3: add support for full color key management
v4: fix copy & paste bug in snb_get_colorkey
don't bother checking min/max values against docs as the docs are likely
wrong (how could we handle 10bpc surface formats?)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This patch removes maxpin member in the pin control descriptor
because we don't need this value as we enumerate a pin space
using offset.
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Obtaining a "struct pinctrl_dev *" is difficult for code not directly
related to the pinctrl subsystem. However, the device name of the pinctrl
device is fairly well known. So, modify pin_config_*() to take the device
name instead of the "struct pinctrl_dev *".
Signed-off-by: Stephen Warren <swarren@nvidia.com>
[rebased on top of refactoring code]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This allows one to include pinconf.h without having to include other
headers first.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
To create elegant tables for pinmux hogs on the PXA MMP platform,
we need this hog macro that can specify both function and group in
one go.
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pin controllers should already be instantiated as a device, so there's
no need for the pinctrl core to create a new struct device for each
controller.
This allows the controller's real name to be used in the mux mapping
table, rather than e.g. "pinctrl.0", "pinctrl.1", etc.
This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since
their sole purpose was to hard-code the .ctrl_dev_name field to be
"pinctrl.0".
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is the same as PINMUX_MAP_PRIMARY_SYS_HOG, except that it allows
you to specify a particular control device.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.
ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
those may support two interfaces using vtables: pin
multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
implement only config without mux, and vice versa, so keep each
sub-functionality of pin controllers separate. Introduce
CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
drive modes, this shall be the number of drive stages vs
nominal load impedance, which should match the actual
electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
on input lines.
- Fix a bug when we tried to configure pins for pin controllers
without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
pin_config_group() functions.
- Drop the entire concept of just getting initial config and
keeping track of pin states internally, instead ask the pins
what state they are in. Previous idea was plain wrong, if the
device cannot keep track of its state, the driver should do
it.
- Drop the generic configuration layout, it seems this impose
too much restriction on some pin controllers, so let them do
things the way they want and split off support for generic
config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
.pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
calls, these belong in the generic config patch. Just pass the
return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
configuration only, also slam in a per-group debug callback in
the pinconf_ops so custom drivers can display something
meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
[get|set]_config() functions, as suggested by Stephen Warren.
This is more natural as names will be what a developer has
access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
the by-name functions externally, expose the by-pin functions
internally.
- Show supported pin control functionality in the debugfs
pinctrl-devices file.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This makes a deep copy of the pinmux function map instead of
keeping the copy supplied from the platform around. This makes
it possible to tag the platforms map with __initdata as is also
done as part of this patch.
Rationale: a certain target platform (PXA) has numerous
pinmux maps, many of which will be lying around unused after
boot in a multi-platform binary. Instead, deep-copy the one
we're going to use and tag them all __initdata so they go away
after boot.
ChangeLog v1->v2:
- Fixup the deep copy, missed a few items on the struct,
plus mark bool member non-const since we're making runtime
copies if this stuff now.
ChangeLog v2->v3:
- Make a shallow copy (just copy the array of map structs)
as Arnd noticed, string constants never get discarded by the
kernel anyway, so these pointers may be safely copied over.
Reviewed-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When requesting a single GPIO pin to be muxed in, some controllers
will need to poke a different value into the control register
depending on whether the pin will be used for GPIO output or GPIO
input. So create pinmux counterparts to gpio_direction_[input|output]
in the pinctrl framework.
ChangeLog v1->v2:
- This also amends the documentation to make it clear the this
function and associated machinery is *ONLY* intended as a backend
to gpiolib machinery, not for everyone and his dog to start playing
around with pins.
ChangeLog v2->v3:
- Don't pass an argument to the common request function, instead
provide pinmux_* counterparts to the gpio_direction_[input|output]
calls, simpler and anyone can understand it.
ChangeLog v3->v4:
- Fix numerous spelling mistakes and dangling text in documentation.
Add Ack and Rewewed-by.
Cc: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch enables mapping a base offset of gpio ranges with
a pin offset even if does'nt matched. A base of pinctrl_gpio_range
means a base offset of gpio. However, we cannot convert gpio to pin
number for sparse gpio ranges just only using a gpio base offset.
We can convert a gpio to real pin number(even if not matched) using
a new pin_base which means a base pin offset of requested gpio range.
Now, the pin control subsystem passes the pin base offset to the
pinmux driver.
For example, let's assume below two gpio ranges in the system.
static struct pinctrl_gpio_range gpio_range_a = {
.name = "chip a",
.id = 0,
.base = 32,
.pin_base = 32,
.npins = 16,
.gc = &chip_a;
};
static struct pinctrl_gpio_range gpio_range_b = {
.name = "chip b",
.id = 0,
.base = 48,
.pin_base = 64,
.npins = 8,
.gc = &chip_b;
};
We can calucalate a exact pin ranges even if doesn't matched with gpio ranges.
chip a:
gpio-range : [32 .. 47]
pin-range : [32 .. 47]
chip b:
gpio-range : [48 .. 55]
pin-range : [64 .. 71]
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
completely different manner than they select which function to mux out of
that pin. In order to support a single "free" pinmux_op, the driver would
need to maintain a per-pin state of requested-for-gpio vs. requested-for-
function. However, that's a lot of work when the core already has explicit
separate paths for gpio request/free and function request/free.
So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
call it when appropriate.
When doing this, I noticed that when calling pin_request():
!!gpio == (gpio_range != NULL)
... and so I collapsed those two parameters in both pin_request(), and
when adding writing the new code in pin_free().
Also, for pin_free():
!!free_func == (gpio_range != NULL)
However, I didn't want pin_free() to know about the GPIO function naming
special case, so instead, I reworked pin_free() to always return the pin's
previously requested function, and now pinmux_free_gpio() calls
kfree(function). This is much more balanced with the allocation having
been performed in pinmux_request_gpio().
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch renames hdev->extfeatures to hdev->host_features since it
holds the extended features Page 1 (aka host features).
Signed-off-by: Andre Guedes <aguedespe@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
regulator_force_disable() was omitted in consumer.h for
!CONFIG_REGULATOR case.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Export compress_offload.h and compress_params.h for userland to use
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We should not forget to try for real server with port 0
in the backup server when processing the sync message. We should
do it in all cases because the backup server can use different
forwarding method.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Now that all frontends are implementing DVBv5, don't export the
DVBv3 specific stuff to the drivers. Only the core should be
aware of that, as it will keep providing DVBv3 backward compatibility.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
During some debugging I needed to look into how /proc/net/ipv6_route
operated and in my digging I found its calling fib6_clean_all() which uses
"write_lock_bh(&table->tb6_lock)" before doing the walk of the table. I
found this on 2.6.32, but reading the code I believe the same basic idea
exists currently. Looking at the rtnetlink code they are only calling
"read_lock_bh(&table->tb6_lock);" via fib6_dump_table(). While I realize
reading from proc isn't the recommended way of fetching the ipv6 route
table; taking a write lock seems unnecessary and would probably cause
network performance issues.
To verify this I loaded up the ipv6 route table and then ran iperf in 3
cases:
* doing nothing
* reading ipv6 route table via proc
(while :; do cat /proc/net/ipv6_route > /dev/null; done)
* reading ipv6 route table via rtnetlink
(while :; do ip -6 route show table all > /dev/null; done)
* Load the ipv6 route table up with:
* for ((i = 0;i < 4000;i++)); do ip route add unreachable 2000::$i; done
* iperf commands:
* client: iperf -i 1 -V -c <ipv6 addr>
* server: iperf -V -s
* iperf results - 3 runs each (in Mbits/sec)
* nothing: client: 927,927,927 server: 927,927,927
* proc: client: 179,97,96,113 server: 142,112,133
* iproute: client: 928,927,928 server: 927,927,927
lock_stat shows taking the write lock is causing the slowdown. Using this
info I decided to write a version of fib6_clean_all() which replaces
write_lock_bh(&table->tb6_lock) with read_lock_bh(&table->tb6_lock). With
this new function I see the same results as with my rtnetlink iperf test.
Signed-off-by: Josh Hunt <joshhunt00@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
While it's not too late fix the recently added RQLEN diag extension
to report rqlen and wqlen in the same way as TCP does.
I.e. for listening sockets the ack backlog length (which is the input
queue length for socket) in rqlen and the max ack backlog length in
wqlen, and what the CINQ/OUTQ ioctls do for established.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently tcp diag reports rqlen and wqlen values similar to how
the CINQ/COUTQ iotcls do. To make unix diag report these values
in the same way move the respective code into helpers.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ Fix indentation of sock_diag*() calls. -DaveM ]
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a routine that dumps memory-related values of a socket.
It's made as an array to make it possible to add more stuff
here later without breaking compatibility.
Since v1: The SK_MEMINFO_ constants are in userspace
visible part of sock_diag.h, the rest is under __KERNEL__.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The headers check complains it should include the linux/types.h
withing, thus add this one.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Properly toss existing components around the ifdef __KERNEL__
and include the header into the header-y target.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The V4L2_CID_ALPHA_COMPONENT control is intended for the video capture
or memory-to-memory devices that are capable of setting up the per-pixel
alpha component to some arbitrary value. It allows to set the alpha
component for all pixels to an arbitrary value.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Linux 3.2-rc7
* tag 'v3.2-rc7': (1304 commits)
Linux 3.2-rc7
netfilter: xt_connbytes: handle negation correctly
Btrfs: call d_instantiate after all ops are setup
Btrfs: fix worker lock misuse in find_worker
net: relax rcvbuf limits
rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
net: introduce DST_NOPEER dst flag
mqprio: Avoid panic if no options are provided
bridge: provide a mtu() method for fake_dst_ops
md/bitmap: It is OK to clear bits during recovery.
md: don't give up looking for spares on first failure-to-add
md/raid5: ensure correct assessment of drives during degraded reshape.
md/linear: fix hot-add of devices to linear arrays.
sparc64: Fix MSIQ HV call ordering in pci_sun4v_msiq_build_irq().
pata_of_platform: Add missing CONFIG_OF_IRQ dependency.
ipv4: using prefetch requires including prefetch.h
VFS: Fix race between CPU hotplug and lglocks
vfs: __read_cache_page should use gfp argument rather than GFP_KERNEL
USB: Fix usb/isp1760 build on sparc
net: Add a flow_cache_flush_deferred function
...
Conflicts:
drivers/media/common/tuners/tda18218.c
drivers/media/video/omap3isp/ispccdc.c
drivers/staging/media/as102/as102_drv.h
Commit 2a95ea6c0d ("procfs: do not overflow get_{idle,iowait}_time
for nohz") did not take into account that one some architectures jiffies
and cputime use different units.
This causes get_idle_time() to return numbers in the wrong units, making
the idle time fields in /proc/stat wrong.
Instead of converting the usec value returned by
get_cpu_{idle,iowait}_time_us to units of jiffies, use the new function
usecs_to_cputime64 to convert it to the correct unit of cputime64_t.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "Artem S. Tashkinov" <t.artem@mailcity.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch is hdmi display support for exynos drm driver.
There is already v4l2 based exynos hdmi driver in drivers/media/video/s5p-tv
and some low level code is already in s5p-tv and even headers for register
define are almost same. but in this patch, we decide not to consider separated
common code with s5p-tv.
Exynos HDMI is composed of 5 blocks, mixer, vp, hdmi, hdmiphy and ddc.
1. mixer. The piece of hardware responsible for mixing and blending multiple
data inputs before passing it to an output device. The mixer is capable of
handling up to three image layers. One is the output of VP. Other two are
images in RGB format. The blending factor, and layers' priority are controlled
by mixer's registers. The output is passed to HDMI.
2. vp (video processor). It is used for processing of NV12/NV21 data. An image
stored in RAM is accessed by DMA. The output in YCbCr444 format is send to
mixer.
3. hdmi. The piece of HW responsible for generation of HDMI packets. It takes
pixel data from mixer and transforms it into data frames. The output is send
to HDMIPHY interface.
4. hdmiphy. Physical interface for HDMI. Its duties are sending HDMI packets to
HDMI connector. Basically, it contains a PLL that produces source clock for
mixer, vp and hdmi.
5. ddc (display data channel). It is dedicated i2c channel to exchange display
information as edid with display monitor.
With plane support, exynos hdmi driver fully supports two mixer layes and vp
layer. Also vp layer supports multi buffer plane pixel formats having non
contigus memory spaces.
In exynos drm driver, common drm_hdmi driver to interface with drm framework
has opertion pointers for mixer and hdmi. this drm_hdmi driver is registered as
sub driver of exynos_drm. hdmi has hdmiphy and ddc i2c clients and controls
them. mixer controls all overlay layers in both mixer and vp.
Vblank interrupts for hdmi are handled by mixer internally because drm
framework cannot support multiple irq id. And pipe number is used to check
which display device irq happens.
History
v2: this version
- drm plane feature support to handle overlay layers.
- multi buffer plane pixel format support for vp layer.
- vp layer support
RFCv1: original
- at https://lkml.org/lkml/2011/11/4/164
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Multi buffer plane pixel format has seperated memory spaces for each
plane. For example, NV12M has Y plane and CbCr plane and these are in
non contiguous memory region. Compared with NV12, NV12M's memory shape
is like following.
NV12 : ______(Y)(CbCr)_______
NV12M : __(Y)_ ..... _(CbCr)__
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
It just obscures that the netdevice pointer and the expires value are
implemented in the dst_entry sub-object of the ipv6 route.
And it makes grepping for dst_entry member uses much harder too.
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, we clear revoked flag only when a block is reused. However,
this can tigger a false journal error. Consider a situation when a block
is used as a meta block and is deleted(revoked) in ordered mode, then the
block is allocated as a data block to a file. At this moment, user changes
the file's journal mode from ordered to journaled and truncates the file.
The block will be considered re-revoked by journal because it has revoked
flag still pending from the last transaction and an assertion triggers.
We fix the problem by keeping the revoked status more uptodate - we clear
revoked flag when switching revoke tables to reflect there is no revoked
buffers in current transaction any more.
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Also, create and use an rt6_bind_neighbour() in net/ipv6/route.c to
consolidate some common logic.
Signed-off-by: David S. Miller <davem@davemloft.net>
In order to perform a proper universal hash on a vector of integers,
we have to use different universal hashes on each vector element.
Which means we need 4 different hash randoms for ipv6.
Signed-off-by: David S. Miller <davem@davemloft.net>
Add empty of_get_node/of_put_node functions for !CONFIG_OF builds.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
It's for migrating to generic clk framework API.
The helper functions help cases clk_enable/clk_disable is used
in non-atomic context.
For example, Call clk_enable in probe and clk_disable in remove.
Signed-off-by: Richard Zhao <richard.zhao@linaro.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Some displays from AUO have a so called in-cell touchscreen, meaning it
is built directly into the display unit.
Touchdata is gathered through PIXCIR Tango-ICs and processed in an
Atmel ATmega168P with custom firmware. Communication between the host
system and ATmega is done via I2C.
Devices using this touch solution include the Dell Streak5 and the family
of Qisda ebook readers.
The driver reports single- and multi-touch events including touch area
values.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
