drivers/xen/xenbus/xenbus_dev_backend.c:74:2: error: implicit declaration of function 'xen_initial_domain'
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: NIan Campbell <ian.campbell@citrix.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Add support for mappings without GNTMAP_contains_pte. This was not
supported because the unmap operation assumed that this flag was being
used; adding a parameter to the unmap operation to allow the PTE
clearing to be disabled is sufficient to make unmap capable of
supporting either mapping type.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
[v1: Fix cleanpatch warnings]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

For xenbus_{map,unmap}_ring to work on HVM, the grant table operations
must be set up using the gnttab_set_{map,unmap}_op functions instead of
directly populating the fields of gnttab_map_grant_ref. These functions
simply populate the structure on paravirtualized Xen; however, on HVM
they must call __pa() on vaddr when populating op->host_addr because the
hypervisor cannot directly interpret guest-virtual addresses.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
[v1: Fixed cleanpatch error]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM.  This also removes the need to use vmlist_lock
on PV by tracking the allocated xenbus rings.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
[v1: Fix compile error when XENBUS_FRONTEND is defined as module]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

drivers/xen/xenbus/xenbus_dev_frontend.c: In function 'xenbus_init':
drivers/xen/xenbus/xenbus_dev_frontend.c:609:2: error: implicit declaration of function 'xen_domain'
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Add the work frontend to the error message because we now also have a
backend device.
Signed-off-by: NBastian Blank <waldi@debian.org>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This was used for ia64. But there is no working ia64 support in sight,
so remove it for now.
Signed-off-by: NBastian Blank <waldi@debian.org>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Access for xenstored to the event channel and pre-allocated ring is
managed via xenfs.  This adds its own character device featuring mmap
for the ring and an ioctl for the event channel.
Signed-off-by: NBastian Blank <waldi@debian.org>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Access to xenbus is currently handled via xenfs. This adds a device
driver for xenbus and makes xenfs use this code.
Signed-off-by: NBastian Blank <waldi@debian.org>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Access to arbitrary hypercalls is currently provided via xenfs. This
adds a standard character device to handle this. The support in xenfs
remains for backward compatibility and uses the device driver code.
Signed-off-by: NBastian Blank <waldi@debian.org>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

When a multi-page mapping of gntalloc is created, the reference counts
of all pages in the vma are incremented. However, the vma open/close
operations only adjusted the reference count of the first page in the
mapping, leaking the other pages. Store a struct in the vm_private_data
to track the original page count to properly free the pages when the
last reference to the vma is closed.
Reported-by: NAnil Madhavapeddy <anil@recoil.org>
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

gnttab_end_foreign_access_ref does not return the grant reference it is
passed to the free list; gnttab_free_grant_reference needs to be
explicitly called. While gnttab_end_foreign_access provides a wrapper
for this, it is unsuitable because it does not return errors.
Reported-by: NAnil Madhavapeddy <anil@recoil.org>
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The event channel number provided to evtchn_get can be provided by
userspace, so needs to be checked against the maximum number of event
channels prior to using it to index into evtchn_to_irq.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page.  This is useful
e.g. for forwarding packets between domains.
Signed-off-by: NAnnie Li <annie.li@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

- They can't be used to map the page (so can only be used in a GNTTABOP_copy
  hypercall).
- It's possible to grant access with a finer granularity than whole pages.
- Xen guarantees that they can be revoked quickly (a normal map grant can
  only be revoked with the cooperation of the domain which has been granted
  access).
Signed-off-by: NAnnie Li <annie.li@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Signed-off-by: NAnnie Li <annie.li@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

virtio pci device reset actually just does an I/O
write, which in PCI is really posted, that is it
can complete on CPU before the device has received it.

Further, interrupts might have been pending on
another CPU, so device callback might get invoked after reset.

This conflicts with how drivers use reset, which is typically:
	reset
	unregister
a callback running after reset completed can race with
unregister, potentially leading to use after free bugs.

Fix by flushing out the write, and flushing pending interrupts.

This assumes that device is never reset from
its vq/config callbacks, or in parallel with being
added/removed, document this assumption.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Guest features selector spelling mistake.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Fix this compile error on s390:

  CC [M]  drivers/virtio/virtio_mmio.o
drivers/virtio/virtio_mmio.c: In function 'vm_get_features':
drivers/virtio/virtio_mmio.c:107:2: error: implicit declaration of function 'writel'

Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Count of selector voltage is required for regulator_set_voltage
to work via set_voltage_sel. VDD1/2 currently have it as zero,
so regulator_set_voltage won't work for VDD1/2.
Update count (n_voltages) for VDD1/2.

Output Voltage = (step value * 12.5 mV + 562.5 mV) * gain

With above expr, number of voltages that can be selected is
step value count * gain count

constant for gain count will be called VDD1_2_NUM_VOLT_COARSE

existing constant for step value count is VDD1_2_NUM_VOLTS,
use VDD1_2_NUM_VOLT_FINE instead to make clear that step value
is not the only component in deciding selectable voltage count
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The function i2cdev_notifier_call is used only in i2c-dev file
making it static.
Also removes the following sparse warning

drivers/i2c/i2c-dev.c:582:5: warning: symbol 'i2cdev_notifier_call'
was not declared. Should it be static?
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

10-bit addresses overlap with traditional 7-bit addresses, leading in
device name collisions. Add an arbitrary offset to 10-bit addresses to
prevent this collision. The offset was chosen so that the address is
still easily recognizable.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>

The wrong bits were put on the wire, fix that.

This fixes kernel bug #42562.
Signed-off-by: NSheng-Hui J. Chu <jeffchu@broadcom.com>
Cc: stable@kernel.org
Signed-off-by: NJean Delvare <khali@linux-fr.org>

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.
Reported-by: NHaogang Chen <haogangchen@gmail.com>
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit dc937280.

As requested by Ben Herrenschmidt:
  "This breaks some powerpc platforms at least.  The practice of having
   a node provide an explicit "interrupt-parent" property pointing to
   itself is an old trick that we've used in the past to allow a
   device-node to have interrupts routed to different controllers.

   In that case, the node also contains an interrupt-map, so the node is
   its own parent, the interrupt resolution hits the map, which then can
   route each individual interrupt to a different parent."

Grant says:
  "Ah, nuts, yes that is broken then.  Yes, please revert the commit and
   Rob & I will come up with a better solution.

   Rob, I think it can be done by explicitly checking for np ==
   desc->interrupt_parent in of_irq_init() instead of relying on
   of_irq_find_parent() returning NULL."
Requested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

kbuf is a buffer that is local to this function, so all of the error paths
leaving the function should release it.
Signed-off-by: NJulia Lawall <julia@diku.dk>
Cc: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Split the quirks and i2c_rec assignment into separate
functions used by both radeon_lookup_i2c_gpio() and
radeon_atombios_i2c_init().  This avoids duplicating code
and cases where quirks were only added to one of the
functions.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

I missed this part the first time through.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

An unlikely race could case a bo to be returned reserved on an error path.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NAnnie Li <annie.li@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.

However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.

Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.

Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.

V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NAnnie Li <annie.li@oracle.com>
[v1: Modified alloc_vm_area call (new parameters), indentation, and cleanpatch
     warnings]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NAnnie Li <annie.li@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This patch introduces new structures of grant table V2, grant table V2 is an
extension from V1. Grant table is shared between guest and Xen, and Xen is
responsible to do corresponding work for grant operations, such as: figure
out guest's grant table version, perform different actions based on
different grant table version, etc. Although full-page structure of V2
is different from V1, it play the same role as V1.
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NAnnie Li <annie.li@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

it can fail and in that case ->release() will *not* be called...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Event channels exposed to userspace by the evtchn module may be used by
other modules in an asynchronous manner, which requires that reference
counting be used to prevent the event channel from being closed before
the signals are delivered.

The reference count on new event channels defaults to -1 which indicates
the event channel is not referenced outside the kernel; evtchn_get fails
if called on such an event channel. The event channels made visible to
userspace by evtchn have a normal reference count.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

When using the unmap notify ioctl, the event channel used for
notification needs to be reserved to avoid it being deallocated prior to
sending the notification.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The event channel release function cannot be called under a spinlock
because it can attempt to acquire a mutex due to the event channel
reference acquired when setting up unmap notifications.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This adds a new optional chunk to the CS ioctl that specifies optional flags
to the CS parser. Why this is useful is explained below. Note that some regs
no longer need the NOP relocation packet if this feature is enabled.
Tested on r300g and r600g with this flag disabled and enabled.

Assume there are two contexts sharing the same mipmapped tiled texture.
One context wants to render into the first mipmap and the other one
wants to render into the last mipmap. As you probably know, the hardware
has a MACRO_SWITCH feature, which turns off macro tiling for small mipmaps,
but that only applies to samplers.
(at least on r300-r500, though later hardware likely behaves the same)

So we want to just re-set the tiling flags before rendering (writing
packets), right? ... No. The contexts run in parallel, so they may
set the tiling flags simultaneously and then fire their command streams
also simultaneously. The last one setting the flags wins, the other one
loses.

Another problem is when one context wants to render into the first and
the last mipmap in one CS. Impossible. It must flush before changing
tiling flags and do the rendering into the smaller mipmaps in another CS.

Yet another problem is that writing copy_blit in userspace would be a mess
involving re-setting tiling flags to please the kernel, and causing races
with other contexts at the same time.

The only way out of this is to send tiling flags with each CS, ideally
with each relocation. But we already do that through the registers.
So let's just use what we have in the registers.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

ET131X is a network device, so it should depend on
NETDEVICES.  (This part won't be needed when the driver
moves to drivers/net/.)  It also uses PHYLIB interfaces,
so it should select PHYLIB.  Fixes these build errors:

ERROR: "phy_connect" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_find_first" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_register" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_alloc" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_stop" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_start" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_free" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_unregister" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_print_status" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_ethtool_gset" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_ethtool_sset" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_mii_ioctl" [drivers/staging/et131x/et131x.ko] undefined!
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: N: Mark Einon <mark.einon@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>