I found that I constantly reuse information for each test case.
It would be nice to just define a variable to reuse.
For example I may have:
TEST_START
[...]
TEST = ssh root@mybox /path/to/my/script
TEST_START
[...]
TEST = ssh root@mybox /path/to/my/script
[etc]
The issue is, I may wont to change that script or one of the other
fields. Then I need to update each line individually.
With the addition of config variables (variables only used during parsing
the config) we can simplify the config files. These variables can
also be defined multiple times and each time the new value will
overwrite the old value.
The convention to use a config variable over a ktest option is to use :=
instead of =.
Now we could do:
USER := root
TARGET := mybox
TEST_SCRIPT := /path/to/my/script
TEST_CASE := ${USER}@${TARGET} ${TEST_SCRIPT}
TEST_START
[...]
TEST = ${TEST_CASE}
TEST_START
[...]
TEST = ${TEST_CASE}
[etc]
Now we just need to update the variables at the top.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
This is a new rc-core device driver for the IR transceivers made by
RedRat Ltd. (http://redrat.co.uk/). It started out life as an
out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge,
by Stephen Cox. He started porting it to what was then ir-core, and I
finally picked it up about two week ago and did a fairly large overhaul
on it, and its now into a state where I'm fairly comfortable submitting
it here for review and inclusion in the kernel. I'm claiming authorship
of this driver, since while it started out as Stephen's work, its
definitely a derivative work now, at 876 lines added and 1698 lines
removed since grabbing it from sourceforge. Stephen's name is retained
as secondary author though, and credited in the headers. Those
interested in seeing how the changes evolved can (at least for now) look
at this branch in my git tree:
http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3
That won't be around forever though, and I'm doing this as a single
commit to go into mainline. Anyway...
I've successfully tested in-kernel decode of rc5, rc6 and nec remotes,
as well as lirc userspace decode of rc5 and rc6. There are still some
quirks here to sort out with rc5 lirc userspace decode, but I'm working
with the RedRat folks themselves to figure out what's going on there
(rc5 lirc decode works, but you only get an event on key release --
in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of
rc6 is working perfectly. Transmit is also working, tested by pointing
the redrat3 at an mceusb transceiver, which happily picked up the
transmitted signals and properly decoded them.
There's no default remote for this hardware, so its somewhat arbitrarily
set to use the Hauppauge RC5 keymap by default. Easily changed out by
way of ir-keytable and irrelevant if you're using lircd for decode.
CC: Chris Dodge <chris@redrat.co.uk>
CC: Andrew Vincer <Andrew.Vincer@redrat.co.uk>
CC: Stephen Cox <scox_nz@yahoo.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
commit a35e2c1b6d (macvlan: use rx_handler_data pointer to store
macvlan_port pointer V2) added a bug in macvlan_port_create()
Steps to reproduce the bug:
# ifenslave bond0 eth0 eth1
# ip link add link eth0 up name eth0#1 type macvlan
->error EBUSY
# ip link add link eth0 up name eth0#1 type macvlan
->panic
Fix: Dont set IFF_MACVLAN_PORT in error case.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Continuing with IR transmit after resuming from suspend seems fairly
useless, given that the only place we can actually end up suspending is
after IR has been send and we're simply mdelay'ing. Lets simplify the
resume path by just waiting on tx to complete in the suspend path, then
we know we can't be transmitting on resume, and reinitialization of the
hardware registers becomes more straight-forward.
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was some rather odd spacing in a few of the ite8709-specific
functions that made it hard to read those sections of code. This is just
a simple reformatting.
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just recently acquired an Asus Eee Box PC with an onboard IR receiver
driven by ite-cir (ITE8713 sub-variant). Works out of the box with the
ite-cir driver in 2.6.39, but stops working after a suspend/resume
cycle. Its fixed by simply reinitializing registers after resume,
similar to what's done in the nuvoton-cir driver. I've not tested with
any other ITE variant, but code inspection suggests this should be safe
on all variants.
Reported-by: Stephan Raue <sraue@openelec.tv>
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Eliminate a possible circular locking lockdep warning
- Make sure we don't try to unregister a vfd on a device w/a vga screen
- Always free imon context after devices are removed (display_close can
just error out w/no context)
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Set a default timeout (matching mceusb.c) and use
ir_raw_event_store_with_filter, which leads to better behavior when
using lirc userspace decoding with this hardware
- Fill in rx_resolution with the value we're using here (50us)
- Wire up input phys and device parent pointer
- Use device_init_wakeup() instead of device_set_wakeup_*()
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We don't need them anymore, so kill:
- REQ_ON_PLUG checks in various places
- !rq_mergeable() check in plug merging
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Add basic RDMA netlink infrastructure that allows for registration of
RDMA clients for which data is to be exported and supplies message
construction callbacks.
Signed-off-by: Nir Muchtar <nirm@voltaire.com>
[ Reorganize a few things, add CONFIG_NET dependency. - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
Currently we take a queue lock on each bio to check if there are any
throttling rules associated with the group and also update the stats.
Now access the group under rcu and update the stats without taking
the queue lock. Queue lock is taken only if there are throttling rules
associated with the group.
So the common case of root group when there are no rules, save
unnecessary pounding of request queue lock.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Now dispatch stats update is lock free. But reset of these stats still
takes blkg->stats_lock and is dependent on that. As stats are per cpu,
we should be able to just reset the stats on each cpu without any locks.
(Atleast for 64bit arch).
On 32bit arch there is a small race where 64bit updates are not atomic.
The result of this race can be that in the presence of other writers,
one might not get 0 value after reset of a stat and might see something
intermediate
One can write more complicated code to cover this race like sending IPI
to other cpus to reset stats and for offline cpus, reset these directly.
Right not I am not taking that path because reset_update is more of a
debug feature and it can happen only on 32bit arch and possibility of
it happening is small. Will fix it if it becomes a real problem. For
the time being going for code simplicity.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Some of the stats are 64bit and updation will be non atomic on 32bit
architecture. Use sequence counters on 32bit arch to make reading
of stats safe.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Currently we take blkg_stat lock for even updating the stats. So even if
a group has no throttling rules (common case for root group), we end
up taking blkg_lock, for updating the stats.
Make dispatch stats per cpu so that these can be updated without taking
blkg lock.
If cpu goes offline, these stats simply disappear. No protection has
been provided for that yet. Do we really need anything for that?
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Soon we will allow accessing a throtl_grp under rcu_read_lock(). Hence
start freeing up throtl_grp after one rcu grace period.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Use same helper function for root group as we use with dynamically
allocated groups to add it to various lists.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
A helper function for the code which is used at 2-3 places. Makes reading
code little easier.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Currently, we allocate root throtl_grp statically. But as we will be
introducing per cpu stat pointers and that will be allocated
dynamically even for root group, we might as well make whole root
throtl_grp allocation dynamic and treat it in same manner as other
groups.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Currently, all the cfq_group or throtl_group allocations happen while
we are holding ->queue_lock and sleeping is not allowed.
Soon, we will move to per cpu stats and also need to allocate the
per group stats. As one can not call alloc_percpu() from atomic
context as it can sleep, we need to drop ->queue_lock, allocate the
group, retake the lock and continue processing.
In throttling code, I check the queue DEAD flag again to make sure
that driver did not call blk_cleanup_queue() in the mean time.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
blkg->key = cfqd is an rcu protected pointer and hence we used to do
call_rcu(cfqd->rcu_head) to free up cfqd after one rcu grace period.
The problem here is that even though cfqd is around, there are no
gurantees that associated request queue (td->queue) or q->queue_lock
is still around. A driver might have called blk_cleanup_queue() and
release the lock.
It might happen that after freeing up the lock we call
blkg->key->queue->queue_ock and crash. This is possible in following
path.
blkiocg_destroy()
blkio_unlink_group_fn()
cfq_unlink_blkio_group()
Hence, wait for an rcu peirod if there are groups which have not
been unlinked from blkcg->blkg_list. That way, if there are any groups
which are taking cfq_unlink_blkio_group() path, can safely take queue
lock.
This is how we have taken care of race in throttling logic also.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Nobody seems to be using cfq_find_alloc_cfqg() function parameter "create".
Get rid of that.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
cgroup unaccounted_time file is created only if CONFIG_DEBUG_BLK_CGROUP=y.
there are some fields which are out side this config option. Fix that.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Group initialization code seems to be at two places. root group
initialization in blk_throtl_init() and dynamically allocated group
in throtl_find_alloc_tg(). Create a common function and use at both
the places.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Since for-2.6.40/core was forked off the 2.6.39 devel tree, we've
had churn in the core area that makes it difficult to handle
patches for eg cfq or blk-throttle. Instead of requiring that they
be based in older versions with bugs that have been fixed later
in the rc cycle, merge in 2.6.39 final.
Also fixes up conflicts in the below files.
Conflicts:
drivers/block/paride/pcd.c
drivers/cdrom/viocd.c
drivers/ide/ide-cd.c
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
We need to take reference to the s_li_request after we take a mutex,
because it might be freed since then, hence result in accessing old
already freed memory. Also we should protect the whole
ext4_remove_li_request() because ext4_li_info might be in the process of
being freed in ext4_lazyinit_thread().
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
For some reason, when we set the mount option "init_itable=0" it
behaves as we would set init_itable=20 which is not right at all.
Basically when we set it to zero we are saying to lazyinit thread not
to wait between zeroing the inode table (except of cond_resched()) so
this commit fixes that and removes the unnecessary condition. The 'n'
should be also properly used on remount.
When the n is not set at all, it means that the default miltiplier
EXT4_DEF_LI_WAIT_MULT is set instead.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Eric Sandeen <sandeen@redhat.com>
For some reason we have been waiting for lazyinit thread to start in the
ext4_run_lazyinit_thread() but it is not needed since it was jus
unnecessary complexity, so get rid of it. We can also remove li_task and
li_wait_task since it is not used anymore.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
In order to make lazyinit eat approx. 10% of io bandwidth at max, we
are sleeping between zeroing each single inode table. For that purpose
we are using timer which wakes up thread when it expires. It is set
via add_timer() and this may cause troubles in the case that thread
has been woken up earlier and in next iteration we call add_timer() on
still running timer hence hitting BUG_ON in add_timer(). We could fix
that by using mod_timer() instead however we can use
schedule_timeout_interruptible() for waiting and hence simplifying
things a lot.
This commit exchange the old "waiting mechanism" with simple
schedule_timeout_interruptible(), setting the time to sleep. Hence we
do not longer need li_wait_daemon waiting queue and others, so get rid
of it.
Addresses-Red-Hat-Bugzilla: #699708
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
core_kernel_data() wants to know if an address looks like kernel
data. IA64 has had _edata forever, but never needed _sdata until
now.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Geert Uytterhoeven ran a dependency checker which kicked out this warning:
+ warning: (ACPI_APEI) selects PSTORE which has unmet direct dependencies (MISC_FILESYSTEMS): => N/A
Randy confirmed that the fix was to "select MISC_FILESYSTEMS" too.
Tested-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Fix to earlier "Simplify invalidate part (try #6)" patch
That patch caused problems with connectathon test 5.
Reviewed-by: Jeff Layton <jlayton@samba.org>
Signed-off-by: Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Fix rated capacity of the HP iPAQ hx4700 3.7V 1800mAh (359113-001) battery. For this battery the value of the rated capacity EEPROM register at 0x32 is 7; thus rated_capacities[7] = 1800.
Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Fix indexing of the 4 active full EEPROM registers. The indexing was out by 1, accessing the EEPROM registers at 0x23 to 0x26 instead of 0x22 to 0x25.
Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
In 2008 Masashi YOKOTA <yokota@pylone.jp> created the virtual
battery driver found here:
http://downloads.pylone.jp/src/virtual_battery/virtual_battery-0.0.1.tar.bz2
It found use out of tree, but was never merged upstream.
Since then the test_power driver has been merged, which provides
very similar functionality.
This patch extends the test_power driver to be more dynamic
at runtime, by merging portions of the Virtual Battery Driver
by Masashi YOKOTA.
With this patch, I can tweak the values in:
/sys/module/test_power/parameters/* and watch the behavior of
the gnome power managment daemon or other battery UI software.
CC: Anton Vorontsov <cbouatmailru@gmail.com>
CC: Akihiro MAEDA <sola.1980.a@gmail.com>
CC: Masashi YOKOTA <yokota@pylone.jp>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
The M420 format is used by the Microsoft LifeCam Studio HD.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[laurent.pinchart@ideasonboard.com: split into v4l/uvcvideo patches]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
M420 is a hybrid YUV 4:2:0 packet/planar format. Two Y lines are
followed by an interleaved U/V line.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[laurent.pinchart@ideasonboard.com: split into v4l/uvcvideo patches]
[laurent.pinchart@ideasonboard.com: add documentation]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support to uvc driver for NOMMU arch including add function
uvc_queue_get_unmapped_area() and make some changes in uvc_queue_mmap().
So that uvc camera can be used on nommu arch like blackfin.
Signed-off-by: Bob Liu <lliubbo@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It shows up on the console despite using "silent" in the bootargs, and
it's really just noise in the boot log since PM init is always called.
Signed-off-by: Sanjeev Premi <premi@ti.com>
Cc: jhnikula@gmail.com
[khilman@ti.com: minor changelog edits]
Signed-off-by: Kevin Hilman <khilman@ti.com>
