Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Commit d8d595df introduced a bug where we did not check for a NULL
return from kmalloc(). Make rsxx_eeh_save_issued_dmas() return an
error for that case, and make the callers handle that.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

This patch removes dynamic allocation on the stack error.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

sizeof() when applied to a pointer typed expression gives the
size of the pointer, not that of the pointed data.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: scameron@beardog.cce.hp.com
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Any partitions added by user space to the loop device were being
left in place after detaching the loop device.  This was because
the detach path issued a BLKRRPART to clean up partitions if
LO_FLAGS_PARTSCAN was set, meaning that the partitions were auto
scanned on attach.  Replace this BLKRRPART with code that
unconditionally cleans up partitions on detach instead.
Signed-off-by: NPhillip Susi <psusi@ubuntu.com>

Modified by Jens to export delete_partition().
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Fix to return a negative error code from the error handling
case, as returned elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

We already have the frame (pfn of the grant page) stored inside struct
grant, so there's no need to keep an aditional list of mapped frames
for a specific request. This reduces memory usage in blkfront.
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xen.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This prevents us from having to call alloc_page while we are preparing
the request. Since blkfront was calling alloc_page with a spinlock
held we used GFP_ATOMIC, which can fail if we are requesting a lot of
pages since it is using the emergency memory pools.

Allocating all the pages at init prevents us from having to call
alloc_page, thus preventing possible failures.
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xen.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

dev_bus_addr returned in the grant ref map operation is the mfn of the
passed page, there's no need to store it in the persistent grant
entry, since we can always get it provided that we have the page.

This reduces the memory overhead of persistent grants in blkback.

While at it, rename the 'seg[i].buf' to be 'seg[i].offset' as
it makes much more sense - as we use that value in bio_add_page
which as the fourth argument expects the offset.

We hadn't used the physical address as part of this at all.
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xen.org
[v1: s/buf/offset/]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The git commit f84adf49
(xen-blkfront: drop the use of llist_for_each_entry_safe)

was a stop-gate to fix a GCC4.1 bug. The appropiate way
is to actually use an list instead of using an llist.

As such this patch replaces the usage of llist with an
list.

Since we always manipulate the list while holding the io_lock, there's
no need for additional locking (llist used previously is safe to use
concurrently without additional locking).
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
CC: stable@vger.kernel.org
[v1: Redid the git commit description]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

We may use foreach_grant_safe in the future with empty lists, so make
sure we can handle them.
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The benefits are:
* code is cleaner
* kmemdup adds additional debugging info useful for tracking the real
place where memory was allocated (CONFIG_DEBUG_SLAB).
Signed-off-by: NMihnea Dobrescu-Balaur <mihneadb@gmail.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Commit 77089926 ("xen/blkback: Seperate the bio allocation and the bio
submission") consolidated the pendcnt updates to just a single write,
neglecting the fact that the error path relied on it getting set to 1
up front (such that the decrement in __end_block_io_op() would actually
drop the count to zero, triggering the necessary cleanup actions).

Also remove a misleading and a stale (after said commit) comment.

CC: stable@vger.kernel.org
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Spotted by Fenguan Wu's super build robot.
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Changes in v2 include:
o Fixed spelling of guarantee.
o Fixed potential memory leak if slot reset fails out.
o Changed list_for_each_entry_safe with list_for_each_entry.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

This patch includes a simple change to the rsxx_pci_remove
function that caused error messages because traffic was halted
too early.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

This patch includes changing the hardware branding name from
IBM RamSan to IBM FlashSystem.

v2 Changes include:
o Removing the unnecessary IBM Vendor ID #define

v1 Changes include:
o Changed all references of RamSan to FlashSystem.
o Changed the vendor/device IDs for the product.
o Changed driver version number.
o Updated the MAINTAINERS file.
o Various other little things.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

This patch includes changes to the cregs locking scheme. Before,
inconsistant locking would occur because of misuse of spin_lock,
spin_lock_bh, and counter parts.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

This patch includes trivial changes that were recommended by
different members of the Linux Community.

Changes include:
o Removing the redundant wmb().
o Formatting
o Various other little things.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

These values shouldn't be negative, but after an overflow their value
can turn into negative, if they are signed. xentop can show bogus
values in this case.
Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
Reported-by: NIchiro Ogino <ichiro.ogino@citrix.co.jp>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

If the frontend is using a non-native protocol (e.g., a 64-bit
frontend with a 32-bit backend) and it sent an unrecognized request,
the request was not translated and the response would have the
incorrect ID.  This may cause the frontend driver to behave
incorrectly or crash.

Since the ID field in the request is always in the same place,
regardless of the request type we can get the correct ID and make a
valid response (which will report BLKIF_RSP_EOPNOTSUPP).

This bug affected 64-bit SLES 11 guests when using a 32-bit backend.
This guest does a BLKIF_OP_RESERVED_1 (BLKIF_OP_PACKET in the SLES
source) and would crash in blkif_int() as the ID in the response would
be invalid.
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Cc: stable@vger.kernel.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

There is a more complete atmel patch-series out by Nick Dyer that fixes
this and other things, but in the meantime this is the minimal thing to
get the touchscreen going on (at least my) Pixel Chromebook.

Not that I want my dirty fingers near that beautiful screen, but it
seems that a non-initialized touchscreen will also end up being a
constant wakeup source, so you have to disable it to go to sleep.  And
it's easier to just fix the initialization sequence.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add basic platform data to get the current upstream driver working
with the 224s touchpad and 1664s touchscreen.
We will be using NULL config so we will use the settings from the
devices' NVRAMs.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Tested-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This same driver can be used by atmel based touchscreens and touchpads
(buttonpads). Platform data may specify a device is a touchpad
using the is_tp flag.

This will cause the driver to perform some touchpad specific
initializations, such as:
  * register input device name "Atmel maXTouch Touchpad" instead of
  Touchscreen.
  * register BTN_LEFT & BTN_TOOL_* event types.
  * register axis resolution (as a fixed constant, for now)
  * register BUTTONPAD property
  * process GPIO buttons using reportid T19

Input event GPIO mapping is done by the platform data key_map array.

key_map[x] should contain the KEY or BTN code to send when processing
GPIOx from T19. To specify a GPIO as not an input source, populate
with KEY_RESERVED, or 0.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Tested-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 9f9c9cbb ("drivers/firmware/dmi_scan.c: fetch dmi version
from SMBIOS if it exists") hoisted the check for "_DMI_" into
dmi_scan_machine(), which means that we don't bother to check for
"_DMI_" at offset 16 in an SMBIOS entry.  smbios_present() may also call
dmi_present() for an address where we found "_SM_", if it failed further
validation.

Check for "_DMI_" in smbios_present() before calling dmi_present().

[akpm@linux-foundation.org: fix build]
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Reported-by: NTim McGrath <tmhikaru@gmail.com>
Tested-by: NTim Mcgrath <tmhikaru@gmail.com>
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit ac24c220 ("drm/tegra: Use generic
HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
statement for that symbol is a nop. Drop it.

What was needed to use HDMI functionality was to select HDMI (which this
entry already did through depending on DRM) and to include linux/hdmi.h
(which this commit also did).
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Acked-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Renesas boards were consistently defaulting to the 1024x768 resolution,
regardless of the native resolution of the monitor plugged in.  It was
determined that the EDID of the monitor was not being read.  Since the
DAC is a shared line, in order to read from or write to it we must take
control of the DAC clock.  This can be done by setting the proper
register to one.

This bug fix sets the register MGA1064_GEN_IO_CTL2 to one.  The DAC
control line can be used to determine whether or not a new monitor has
been plugged in.  But since the hotplug feature is not one we will
support, it has been decided to simply leave the register set to one.
Signed-off-by: NJulia Lemire <jlemire@matrox.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A monitor or a user could request a resolution greater than the
available VRAM for the backing framebuffer. This change checks the
required framebuffer size against the max VRAM size and rejects modes
if they are too big. This change can also remove a mode request passed
in via the video= parameter.
Signed-off-by: NChristopher Harvey <charvey@matrox.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NChristopher Harvey <charvey@matrox.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The MIP_ADDRESS state has 2 meanings. If the texture has one sample
per pixel, it's a pointer to the mipmap chain. If the texture has
multiple samples per pixel, it's a pointer to FMASK, a metadata buffer
needed for reading compressed MSAA textures. The mipmap
alignment rules do not apply to FMASK.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The MC is mostly likely busy (e.g., display requests), not hung
so no need to reset it.  Doing an MC reset is tricky and not
particularly reliable.  Fixes hangs in certain cases.
Reported-by: NJosh Boyer <jwboyer@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

vbios values are wrong leading to colors that are
too bright.  Use the default values instead.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Avoids splatter if the interrupt handler is not registered due
to acceleration being disabled.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org

hid_output_raw_report() makes a direct call to usb_control_msg(). However,
some USB3 boards have shown that the usb device is not ready during the
.probe(). This blocks the entire usb device, and the paired mice, keyboards
are not functional. The dmesg output is the following:

[   11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
[   11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32
[   11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32

Relying on the scheduled call to usbhid_submit_report() fixes the problem.

related bugs:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143
https://bugzilla.redhat.com/show_bug.cgi?id=840391
https://bugzilla.kernel.org/show_bug.cgi?id=49781Reported-and-tested-by: NBob Bowles <bobjohnbowles@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It seems some VMs support the P state MSRs but return zeros. Fail
gracefully if we are running in this environment.

References: https://bugzilla.redhat.com/show_bug.cgi?id=916833Reported-by: NJosh Boyer <jwboyer@redhat.com>
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If cpufreq_register_driver() fails just free memory that has been
allocated and return. intel_pstate_exit() function is removed since we
are built-in only now there is no reason for a module exit procedure.
Reported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

According to PRM we need to disable hsync and vsync even though ADPA is
disabled. The previous code did infact do the opposite so we fix it.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359Tested-by: Nmax <manikulin@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Joseph was hitting a failure case when mounting efivarfs which
resulted in an incorrect error message,

  $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory

triggered when efivarfs_valid_name() returned -EINVAL.

Make sure we pass accurate return values up the stack if
efivarfs_fill_super() fails to build inodes for EFI variables.
Reported-by: NJoseph Yasi <joe.yasi@gmail.com>
Reported-by: NLingzhu Xiang <lxiang@redhat.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: <stable@vger.kernel.org> # v3.8
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>