We emulate the barrier requests by draining the outstanding bio's
and then sending the WRITE_FLUSH command. To drain the I/Os
we use the refcnt that is used during disconnect to wait for all
the I/Os before disconnecting from the frontend. We latch on its
value and if it reaches either the threshold for disconnect or when
there are no more outstanding I/Os, then we have drained all I/Os.
Suggested-by: NChristopher Hellwig <hch@infradead.org>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

... though after a failed xenbus_register_frontend() all may be lost.
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Guard against issuing BLKIF_OP_WRITE_BARRIER or BLKIF_OP_FLUSH_CACHE
by checking whether we successfully negotiated with the backend.
The negotiation with the backend also sets the q->flush_flags which
fortunately for us is also used when submitting an bio to us. If
we don't support barriers or flushes it would be set to zero so
we should never end up having to deal with REQ_FLUSH | REQ_FUA.

However, other third party implementations of __make_request that
might be stacked on top of us might not be so smart, so lets fix this up.
Acked-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This fixes the problem of three of those four memset()-s having
improper size arguments passed: Sizeof a pointer-typed expression
returns the size of the pointer, not that of the pointed to data.

It also reverts using kmalloc() instead of kzalloc() for the allocation
of the pending grant handles array, as that array gets fully
initialized in a subsequent loop.
Reported-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This patch fixes belows:

1. Fix code style issue.
2. Fix incorrect functions name in comments.
Signed-off-by: NJoe Jin <joe.jin@oracle.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

When we get -EOPNOTSUPP response for a discard request, we will clear
the discard flag on the request queue so we won't attempt to send discard
requests to backend again, and this should be protected under rq->queue_lock.
However, when we setup the request queue, we pass blkif_io_lock to
blk_init_queue so rq->queue_lock is blkif_io_lock indeed, and this lock
is already taken when we are in blkif_interrpt, so remove the
spin_lock/spin_unlock when we clear the discard flag or we will end up
with deadlock here
Signed-off-by: NLi Dongyang <lidongyang@novell.com>
[v1: Updated description a bit and removed comment from source]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

If the backend advertises 'feature-discard', then interrogate
the backend for alignment and granularity. Setup the request
queue with the appropiate values and send the discard operation
as required.
Signed-off-by: NLi Dongyang <lidongyang@novell.com>
[v1: Amended commit description]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

..aka ATA TRIM/SCSI UNMAP command to be passed through the frontend
and used as appropiately by the backend. We also advertise
certain granulity parameters to the frontend so it can plug them in.
If the backend is a realy device - we just end up using
'blkdev_issue_discard' while for loopback devices - we just punch
a hole in the image file.
Signed-off-by: NLi Dongyang <lidongyang@novell.com>
[v1: Fixed up pr_debug and commit description]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Commit d006199e72a9 ("serial: sh-sci: Regtype probing doesn't need to be
fatal.") made sci_init_single() return when sci_probe_regmap() succeeds,
although it should return when sci_probe_regmap() fails.  This causes
systems using the serial sh-sci driver to crash during boot.

Fix the problem by using the right return condition.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.
Reported-by: NDan Kaminsky <dan@doxpara.com>
Tested-by: NWilly Tarreau <w@1wt.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Two additional savage4 variants were added, but the S3_SAVAGE4_SERIES
macro was incompletely modified, resulting in a false positive detection
of a savage4 card regardless of which savage card is actually present.

For non-savage4 series cards, such as a Savage/IX-MV card, this results
in garbled video and/or a hard-hang at boot time.  Fix this by changing
an '||' to an '&&' in the S3_SAVAGE4_SERIES macro.
Signed-off-by: NJohn P. Stanley <jpsinthemix@verizon.net>
Reviewed-by: NTormod Volden <debian.tormod@gmail.com>
[ The macros have incomplete parenthesis too, but whatever ..  -Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 9c921c22
Author: Lan Tianyu <tianyu.lan@intel.com>

    ACPI / Battery: Resolve the race condition in the sysfs_remove_battery()

fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side
effect made lockdep unhappy with sysfs_remove_battery():

[14818.477168]
[14818.477170] =======================================================
[14818.477200] [ INFO: possible circular locking dependency detected ]
[14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668
[14818.477236] -------------------------------------------------------
[14818.477257] s2ram/1599 is trying to acquire lock:
[14818.477276]  (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a
[14818.477323]
[14818.477325] but task is already holding lock:
[14818.477350]  (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery]
[14818.477395]
[14818.477397] which lock already depends on the new lock.
[14818.477399]
[..]
[14818.479121] stack backtrace:
[14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668
[14818.479175] Call Trace:
[14818.479198]  [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4
[14818.479228]  [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b
[14818.479260]  [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a
[14818.479288]  [<ffffffff810718d2>] lock_acquire+0x138/0x1ac
[14818.479316]  [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a
[14818.479345]  [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec
[14818.479373]  [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a
[14818.479405]  [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a
[14818.479433]  [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77
[14818.479461]  [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14
[14818.479488]  [<ffffffff81385bf8>] device_remove_file+0x12/0x14
[14818.479516]  [<ffffffff81386504>] device_del+0x119/0x17c
[14818.479542]  [<ffffffff81386575>] device_unregister+0xe/0x1a
[14818.479570]  [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27
[14818.479601]  [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery]
[14818.479632]  [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery]
[14818.479662]  [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1
[14818.479692]  [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89
[14818.479722]  [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11
[14818.479751]  [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27
[14818.479770]  [<ffffffff8107ee1a>] enter_state+0xa7/0xd5
[14818.479782]  [<ffffffff8107e341>] state_store+0xaa/0xc0
[14818.479795]  [<ffffffff8107e297>] ? pm_async_store+0x45/0x45
[14818.479807]  [<ffffffff81248837>] kobj_attr_store+0x17/0x19
[14818.479820]  [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f
[14818.479834]  [<ffffffff81109037>] vfs_write+0xad/0x13d
[14818.479847]  [<ffffffff811092b2>] sys_write+0x45/0x6c
[14818.479860]  [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b

This patch introduces separate lock to struct acpi_battery to
grab in sysfs_remove_battery() instead of battery->lock.
So fix by Lan Tianyu is still there, we just grab independent lock.
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Tested-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Currently the use of pm_runtime_put_sync() is not safe from
interrupts-disabled context because rpm_idle() will release the
spinlock and enable interrupts for the idle callbacks.  This enables
interrupts during a time where interrupts were expected to be
disabled, and can have strange side effects on drivers that expected
interrupts to be disabled.

This is not a bug since the documentation clearly states that only
_put_sync_suspend() is safe in IRQ-safe mode.

However, pm_runtime_put_sync() could be made safe when in IRQ-safe
mode by releasing the spinlock but not re-enabling interrupts, which
is what this patch aims to do.

Problem was found when using some buggy drivers that set
pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
context.
Reported-by: NColin Cross <ccross@google.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The local variable ret is defined twice in pm_genpd_poweron(), which
causes this function to always return 0, even if the PM domain's
.power_on() callback fails, in which case an error code should be
returned.

Remove the wrong second definition of ret and additionally remove an
unnecessary definition of wait from pm_genpd_poweron().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The AMW0 function in acer-wmi works on Lenovo ideapad S205 for control
the wifi hardware state. We also found there have a 0x78 EC register
exposes the state of wifi hardware switch on the machine.

So, add this patch to support Lenovo ideapad S205 wifi hardware switch
in acer-wmi driver.

Reference: bko#37892
	https://bugzilla.kernel.org/show_bug.cgi?id=37892

Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Thomas Renninger <trenn@suse.de>
Tested-by: NFlorian Heyer <heyho@flanto.de>
Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

It seems that aliases shouldn't contain spaces, as
module-init-tools uses them as delimeters in module.alias file
Signed-off-by: NAnton V. Boyarshinov <boyarsh@altlinux.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

In the case of ideapad_backlight_init() failure,
we need to free the resources allocated by ideapad_input_init().

Aslo drop __devexit annotation for ideapad_input_exit() because
we also call it in ideapad_acpi_add() error path.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

When enabling turbo, we need to set both the TDC and TDP bits.  IIRC
only the TDC one actually matters, but fix it up anyway since the
current code is confusing.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Some samsung latop of the N150/N2{10,20,30} serie are badly detected by the samsung-laptop platform driver, see bug # 36082.
It appears that N230 identifies itself as N150/N210/N220/N230 whereas the other identify themselves as N150/N210/220.
This patch attemtp fix #36082 allowing correct identification for all the said netbook model.
Reported-by: NDaniel Eklöf <daniel@ekloef.se>
Signed-off-by: NThomas Courbon <thcourbon@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

All of these keys are being reported on the keyboard
controller but are also generating WMI events. Add them
to the legacy keymap to silence the noise.

BugLink: http://bugs.launchpad.net/bugs/815914Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

We only care about if there is any successful match from the dmi table
or no match at all, we can make dmi_check_system return immediately if
we have a successful match instead of iterate thorough the whole table.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

This adds backlight control on the Samsung Q10 laptop, which does not support
the SABI interface. Also tested successfully on the Dell Latitude X200.
Signed-off-by: NFrederick van der Wyck <fvanderwyck@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

And also remove unused variable 'my_id_table'.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Otherwise, the error path will always be executed.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The memory for td_info which is allocated in initialize_sensor()
should be properly kfreed in mid_thermal_probe() error patch and
mid_thermal_remove().
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The N510 benefits from this code as well. Below is a patch to include support.
Signed-off-by: NJouke Witteveen <j.witteveen@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

ref: http://dev.iksaif.net/projects/3/wiki/Asus-laptop_WAPFSigned-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Cc: stable@kernel.org
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Based on a patch from Nate Weibley. <nweibley@gmail.com>.

Cc: Nate Weibley <nweibley@gmail.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The T101MT Home/Express Gate key autorepeats in hardware, but
sparse-keymap does not support hardware autorepeat. Enable the
input core's software autorepeat to emulate the hardware behavior.
Normal hotkeys are autoreleased, so the behavior of these keys
will not be affected.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>