With ACPI 5 we are starting to see devices that don't natively support
discovery but can be enumerated with the help of the ACPI namespace.
Typically, these devices can be represented in the Linux device driver
model as platform devices or some serial bus devices, like SPI or I2C
devices.

Since we want to re-use existing drivers for those devices, we need a
way for drivers to specify the ACPI IDs of supported devices, so that
they can be matched against device nodes in the ACPI namespace.  To
this end, it is sufficient to add a pointer to an array of supported
ACPI device IDs, that can be provided by the driver, to struct device.

Moreover, things like ACPI power management need to have access to
the ACPI handle of each supported device, because that handle is used
to invoke AML methods associated with the corresponding ACPI device
node.  The ACPI handles of devices are now stored in the archdata
member structure of struct device whose definition depends on the
architecture and includes the ACPI handle only on x86 and ia64. Since
the pointer to an array of supported ACPI IDs is added to struct
device_driver in an architecture-independent way, it is logical to
move the ACPI handle from archdata to struct device itself at the same
time.  This also makes code more straightforward in some places and
follows the example of Device Trees that have a poiter to struct
device_node in there too.

This changeset is based on Mika Westerberg's work.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Acked-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This adds sparc support for platform_get_irq that in the normal case use
platform_get_resource() to get an irq. This standard approach fails for sparc as
there are no resources of type IORESOURCE_IRQ for irqs for sparc.

Cross platform drivers can then use this standard platform function and work on
sparc instead of having to have a special case for sparc.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If a gianfar ethernet device is down prior to hibernating a
system, it will no longer be present upon system restore.

For example:

	~# ifconfig eth0 down
	~# echo disk > /sys/power/state

	  <trigger a restore from hibernation>

	~# ifconfig eth0 up
	SIOCSIFFLAGS: No such device

This happens because the restore function bails out early upon
finding devices that were not up at hibernation.  In doing so,
it never gets to the netif_device_attach call at the end of
the restore function.  Adding the netif_device_attach as done
here also makes the gfar_restore code consistent with what is
done in the gfar_resume code.

Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: NWang Dongsheng <dongsheng.wang@freescale.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

when something goes wrong, a flood of these messages can be
generated by usbnet (thousands per second).  This doesn't
generally *help* the condition so this patch ratelimits the
rate of their generation.

There's an underlying problem in usbnet's kevent deferral
mechanism which needs fixing, specifically that events *can*
get dropped and not handled.  This patch doesn't address this,
but just mitigates fallout caused by the current implemention.
Signed-off-by: NSteve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NDmitry Torokhov <dtor@vmware.com>
Cc: stable@vger.kernel.org
Cc: linux-graphics-maintainer@vmware.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

The device would not reset properly when resuming from hibernation.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NDmitry Torokhov <dtor@vmware.com>
Cc: stable@vger.kernel.org
Cc: linux-graphics-maintainer@vmware.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

Virtio wants to release used indices after the corresponding
virtio device has been unregistered. However, virtio does not
hold an extra reference, giving up its last reference with
device_unregister(), making accessing dev->index afterwards
invalid.

I actually saw problems when testing my (not-yet-merged)
virtio-ccw code:

- device_add virtio-net,id=xxx
-> creates device virtio<n> with n>0

- device_del xxx
-> deletes virtio<n>, but calls ida_simple_remove with an
   index of 0

- device_add virtio-net,id=xxx
-> tries to add virtio0, which is still in use...

So let's save the index we want to release before calling
device_unregister().
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
Cc: stable@kernel.org
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Commit c0077061 accidentally inverted the logic for nouveau_acpi_edid,
causing it to only show a connector as connected when the edid could not
be retrieved with acpi.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NKelly Doran <kel.p.doran@gmail.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It slipped in thanks to typeless API.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nv04_graph_priv / nv04_graph_chan are not defined in this context...
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It's a miracle it compiles at all - nv04_vm_priv does not exist
anywhere in the tree.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This register is needed for streamout to work properly.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>

These regs were being wronly rejected leading to rendering
issues.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=56876Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>

cdc_eem frames might need to contain 802.1Q VLAN Ethernet frames.
URB/skb sizing from usbnet will default to the hard_mtu,
so account for the VLAN header by expanding that via hard_header_len
Signed-off-by: NIan Coolidge <iancoolidge@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Checking skb->len against ETH_FRAME_LEN assumes a 1514
ethernet frame size. With an 802.1Q VLAN header, ethernet
frame length can now be 1518. Validate frame length against that.
Signed-off-by: NIan Coolidge <iancoolidge@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

INGPADBOUNDARY_MASK is already shifted. No need to shift it again. On reloading
a driver it was resulting in a bad SGE FL MTU sizes [1536, 9088] error. This
only causes an issue on systems that have L1 cache size of 32B, 128B, 512B,
2048B or 4096B.
Signed-off-by: NJay Hernandez <jay@chelsio.com>
Signed-off-by: NVipul Pandya <vipul@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It doesn't make much sense to enable ISDN services if you don't
intend to connect to a network. Therefore insisting that ISDN
depends on NETDEVICES seems logical. We can then remove any
guards mentioning NETDEVICES inside all subordinate drivers.

This also has the nice side-effect of fixing the warning below
when ISDN_I4L && !CONFIG_NETDEVICES at compile time.

This patch fixes:
drivers/isdn/i4l/isdn_common.c: In function ‘isdn_ioctl’:
drivers/isdn/i4l/isdn_common.c:1278:8: warning: unused variable ‘s’ [-Wunused-variable]

Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: netdev@vger.kernel.org
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We should not assume reserve fields to be don't cares as fields may change.
Clearing data structures before using.
Signed-off-by: NJay Hernandez <jay@chelsio.com>
Signed-off-by: NVipul Pandya <vipul@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If host clock is disabled, host cannot detect a card in case of using
CD internal for detection.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The of_device_id match data is now marked as const and
must not be modified. This changes the dw_mmc to mark
all pointers passing the dw_mci_drv_data or dw_mci_dma_ops
structures as const, and also marks the static definitions
as const.

drivers/mmc/host/dw_mmc-exynos.c: In function 'dw_mci_exynos_probe':
drivers/mmc/host/dw_mmc-exynos.c:234:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Will Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The MODULE_DEVICE_TABLE entry for dw_mci_exynos_match
was incorrectly copied from the platform back-end, which
causes this error when building the driver as a loadable
module:

drivers/mmc/host/dw_mmc-exynos.c: At top level:
drivers/mmc/host/dw_mmc-exynos.c:226:34: error: '__mod_of_device_table' aliased to undefined symbol 'dw_mci_pltfm_match'

This patch fixes the problem by just using the correct
string.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Will Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit 473b095a ("mmc: sdhci: fix incorrect command used in tuning")
introduced a NULL dereference at resume-time if an SD 3.0 host controller
raises the SDHCI_NEEDS_TUNING flag while no card is inserted.  Seen on an
OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too.
Signed-off-by: NChris Ball <cjb@laptop.org>
Cc: stable <stable@vger.kernel.org> [3.3+]

There are two problems here:

The check for vmmc was printing an unnecessary pr_info() when
host->vmmc is NULL.

The intent of the check for vqmmc was to only remove UHS if we have a
regulator that doesn't support the required voltage, but since IS_ERR()
doesn't catch NULL, we were actually removing UHS modes if vqmmc isn't
present at all -- since it isn't present for most users, this breaks
UHS for them.  This patch fixes that UHS regression in 3.7-rc1.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NBin Wang <binw@marvell.com>
Reviewed-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

1. Never ever publish a device in the system before it has been setup
   to a usable state.
2. Unregister the device _BEFORE_ taking away any resources it may be
   using.
3. Don't check clks against NULL.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

A recent commit "mmc: sh_mmcif: fix clock management" has introduced a
use after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to
mmc_free_host() frees private driver data, therefore using it afterwards
is a bug. Revert that hunk.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: stable@vger.kernel.org [3.6]
Signed-off-by: NChris Ball <cjb@laptop.org>

The SDHCI standard defines a 256 byte register set but a device
that specifies a larger iomem region is not an error.  Alter the
message condition accordingly.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The correct name for the driver is "mxc-mmc".
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

dev->platform_data is NULL in case of device tree boot,
instead use the saved version in struct omap_hsmmc_host.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

struct omap_hsmmc_host *host should not be accessed after mmc_free_host().
Reorder mmc_free_host() after iounmap(host->base).
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

800d78bf ("mmc: dw_mmc: add support for implementation specific
callbacks") -- merged in v3.7-rc1 -- introduced multiple NULL pointer
dereferences when the default dw_mci_pltfm_probe() is used, as it sets
host->drv_data to NULL, and that's only checked against NULL in 1 out of
the 7 cases where it is dereferenced.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

As mmc_start_host is getting called before enabling the dw_mmc controller
interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the
very first command sent by the sdio_reset.

This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG=n.
This patch enables the dw_mmc controller interrupt before mmc_start_host.
Signed-off-by: NYuvaraj CD <yuvaraj.cd@samsung.com>
Reviewed-by: NGirish K S <girish.shivananjappa@linaro.org>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

CMD23 causes lots of errors in kernel on some freescale SoCs
(P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
which is because these controllers does not support CMD23,
even on the SoCs which declares CMD23 is supported.
Therefore, we'll not use CMD23.
Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch removes the following warning.
drivers/mmc/host/dw_mmc.c:1976: warning: passing argument 1 of
'_dev_info' from incompatible pointer type
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

As there is no need for it (the fallback code is for older
hypervisors and they only run under x86), and also b/c
we get:

drivers/xen/fallback.c: In function 'xen_event_channel_op_compat':
drivers/xen/fallback.c:10:19: error: storage size of 'op' isn't known
drivers/xen/fallback.c:15:2: error: implicit declaration of function '_hypercall1' [-Werror=implicit-function-declaration]
drivers/xen/fallback.c:15:19: error: expected expression before 'int'
drivers/xen/fallback.c:18:7: error: 'EVTCHNOP_close' undeclared (first use in this function)
drivers/xen/fallback.c:18:7: note: each undeclared identifier is reported only once for each function it appears in
.. and more

[v1: Moved the enablement to be covered by CONFIG_X86 per Ian's suggestion]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

exit_idle() should be called after irq_enter(), otherwise it throws:

[ INFO: suspicious RCU usage. ]
3.6.5 #1 Not tainted
-------------------------------
include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
 #0:  (rcu_read_lock){......}, at: [<ffffffff810e9fe0>] __atomic_notifier_call_chain+0x0/0x140

stack backtrace:
Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1
Call Trace:
 <IRQ>  [<ffffffff811259a2>] lockdep_rcu_suspicious+0xe2/0x130
 [<ffffffff810ea10c>] __atomic_notifier_call_chain+0x12c/0x140
 [<ffffffff810e9fe0>] ? atomic_notifier_chain_unregister+0x90/0x90
 [<ffffffff811216cd>] ? trace_hardirqs_off+0xd/0x10
 [<ffffffff810ea136>] atomic_notifier_call_chain+0x16/0x20
 [<ffffffff810777c3>] exit_idle+0x43/0x50
 [<ffffffff81568865>] xen_evtchn_do_upcall+0x25/0x50
 [<ffffffff81aa690e>] xen_do_hypervisor_callback+0x1e/0x30
 <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
 [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
 [<ffffffff81061540>] ? xen_safe_halt+0x10/0x20
 [<ffffffff81075cfa>] ? default_idle+0xba/0x570
 [<ffffffff810778af>] ? cpu_idle+0xdf/0x140
 [<ffffffff81a4d881>] ? rest_init+0x135/0x144
 [<ffffffff81a4d74c>] ? csum_partial_copy_generic+0x16c/0x16c
 [<ffffffff82520c45>] ? start_kernel+0x3db/0x3e8
 [<ffffffff8252066a>] ? repair_env_string+0x5a/0x5a
 [<ffffffff82520356>] ? x86_64_start_reservations+0x131/0x135
 [<ffffffff82524aca>] ? xen_start_kernel+0x465/0x46

Git commit 98ad1cc1
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date:   Fri Oct 7 18:22:09 2011 +0200

    x86: Call idle notifier after irq_enter()

did this, but it missed the Xen code.
Signed-off-by: NMojiong Qiu <mjqiu@tencent.com>
Cc: stable@vger.kernel.org # from 3.3 and newer.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The order shouldn't matter, but this seems to cause regressions for
certain specific cases.  This should fix it for now.  We probably
need to investigate a proper fix in the next development cycle.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Andy Furniss <andyqos@ukfsn.org>

Add missing index that may have led us to enabling
more crtcs than necessary.

May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have to set dev->dev_mapping
earlier in the process.

Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-October/029420.htmlSigned-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reported-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: stable@vger.kernel.org
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>