All macros used for creating different kind of clocks have similar code for
initializing struct clk. This patch removes those redundant lines and create
another macro DEFINE_CLK.
Signed-off-by: NViresh Kumar <viresh.kumar@st.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

CLK_MUX_INDEX_BIT is mistakenly written as CLK_MUX_INDEX_BITWISE in comment. Fix
it.

CLK_GATE_SET_TO_DISABLE is mistakenly written as CLK_GATE_SET_DISABLE in
comment. Fix it.
Signed-off-by: NViresh Kumar <viresh.kumar@st.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

For most of .set_rate implementation, parent_rate will be used, so just
like passing parent_rate into .recalc_rate, let's pass parent_rate into
.set_rate too.

It also updates the kernel doc for .set_rate ops.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

This patch is the basic clk version of 'clk: core: copy parent_names &
return error codes'.

The registration functions are changed to allow the core code to copy
the array of strings and allow platforms to declare those arrays as
__initdata.

This patch also converts all of the basic clk registration functions to
return error codes which better aligns them with the existing clk.h api.
Signed-off-by: NMike Turquette <mturquette@linaro.org>

This patch cleans up clk_register and solves a few bugs by teaching
clk_register and __clk_init to return error codes (instead of just NULL)
to better align with the existing clk.h api.

Along with that change this patch also introduces a new behavior whereby
clk_register copies the parent_names array, thus allowing platforms to
declare their parent_names arrays as __initdata.
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Drivers should be able to declare their arrays of parent names as const
so the APIs need to accept const arguments.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
[mturquette@linaro.org: constified gate]
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The comment is inaccurate (it actually ends the CONFIG_COMMON_CLK
section, there's no else) and given that we've just got a single level
of ifdef isn't really needed anyway.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Besides the static initialization, the clk_ops of basic clks could
also be used by particular clk type being subclass of the basic clks.

For example, clk_busy_divider has the same clk_ops as clk_divider,
except it has to wait for a busy bit before return success with
.set_rate.  clk_busy_divider will somehow reuse clk_ops of clk_divider.

Since clk-provider.h is included by clk-private.h, it's safe to move
those clk_ops declaration of basic clks form  clk-private.h into
clk-provider.h, so that implementation of clks like clk_busy_divider
above do not need to include clk-private.h to access those clk_ops.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The clk_ops of basic clks should have "const" to match the definition
in "struct clk" and clk_register prototype.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

it's always current->mm
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

MMC bus is using legacy suspend/resume method, which is not compatible if
runtime pm callbacks are used. In this scenario, MMC bus suspend/resume
callbacks cannot be called when system entering S3. So change to use the
new defined dev_pm_ops for system sleeping mode.

Tested on AM335x Platform. Solves major issue/crash reported at
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg65425.htmlSigned-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Tested-by: NHebbar, Gururaja <gururaja.hebbar@ti.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This continues the theme started with vm_brk() and vm_munmap():
vm_mmap() does the same thing as do_mmap(), but additionally does the
required VM locking.

This uninlines (and rewrites it to be clearer) do_mmap(), which sadly
duplicates it in mm/mmap.c and mm/nommu.c.  But that way we don't have
to export our internal do_mmap_pgoff() function.

Some day we hopefully don't have to export do_mmap() either, if all
modular users can become the simpler vm_mmap() instead.  We're actually
very close to that already, with the notable exception of the (broken)
use in i810, and a couple of stragglers in binfmt_elf.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Like the vm_brk() function, this is the same as "do_munmap()", except it
does the VM locking for the caller.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It does the same thing as "do_brk()", except it handles the VM locking
too.

It turns out that all external callers want that anyway, so we can make
do_brk() static to just mm/mmap.c while at it.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The combination of commit 1b1247dd

    "mfd: Add support for RICOH PMIC RC5T583"

and commit 6ffc3270

    "regulator: Add support for RICOH PMIC RC5T583 regulator"

are causing the i386 allmodconfig builds to fail with this:

  ERROR: "rc5t583_update" [drivers/regulator/rc5t583-regulator.ko] undefined!
  ERROR: "rc5t583_set_bits" [drivers/regulator/rc5t583-regulator.ko] undefined!
  ERROR: "rc5t583_clear_bits" [drivers/regulator/rc5t583-regulator.ko] undefined!
  ERROR: "rc5t583_read" [drivers/regulator/rc5t583-regulator.ko] undefined!

and this:

  ERROR: "rc5t583_ext_power_req_config" [drivers/regulator/rc5t583-regulator.ko] undefined!

For the 1st four, make the simple ops static inline, instead of
polluting the namespace with trivial exports.  For the last one,
add an EXPORT_SYMBOL.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The cld.h file contains the definition of the upcall format to talk
with nfsdcld. When I added the file though, I neglected to add it
to the headers-y target, so make headers_install wasn't installing it.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Complete the separation of the twl6040 from the twl core since
it is a separate chip, not part of the twl6030 PMIC.

Make the needed Kconfig changes for the depending drivers at the
same time to avoid breaking the kernel build (vibra, ASoC components).
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonicro.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The ux500 default config enables the db5500 and the db8500.
The incoming cpuidle driver uses the 'prcmu_enable_wakeups'
and the 'prcmu_set_power_state' functions but these ones
are defined but not implemented for the db5500, leading to
an unresolved symbol error at link time. In order to compile,
we have to disable the db5500 support which is not acceptable
for the default config.

I noticed there are also some other functions which are
defined but not implemented.

This patch fix this by removing the functions definitions
and move out of the config section the empty functions which
are normally used when the DB550 config is disabled.
Only the functions which are not implemented are concerned
by this modification.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Commit 18a4d0a2 ("[SCSI] Handle disk devices which can not process
medium access commands") introduced a bug in which we would attempt to
dereference the scsi driver even when the device had no ULD attached.

Ensure that a driver is registered and make the driver accessor function
more resilient to errors during device discovery.
Reported-by: NElric Fu <elricfu1@gmail.com>
Reported-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

GCC's NULL is actually __null, which allows detecting some questionable
NULL usage and warn about it.  Moreover each platform/compiler should
have its own stddef.h anyway (which is different from linux/stddef.h).

So there's no good reason to leak kernel's NULL to userspace and
override what the compiler provides.
Signed-off-by: NLuboš Luňák <l.lunak@suse.cz>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The AMBA bus regulator support is being used to model on/off switches
for power domains which isn't terribly idiomatic for modern kernels with
the generic power domain code and creates integration problems on platforms
which don't use regulators for their power domains as it's hard to tell
the difference between a regulator that is needed but failed to be provided
and one that isn't supposed to be there (though DT does make that easier).

Platforms that wish to use the regulator API to manage their power domains
can indirect via the power domain interface.

This feature is only used with the vape supply of the db8500 PRCMU
driver which supplies the UARTs and MMC controllers, none of which have
support for managing vcore at runtime in mainline (only pl022 SPI
controller does).  Update that supply to have an always_on constraint
until the power domain support for the system is updated so that it is
enabled for these users, this is likely to have no impact on practical
systems as probably at least one of these devices will be active and
cause AMBA to hold the supply on anyway.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Using IS_ENABLED() within C (vs.  within CPP #if statements) in its
current form requires us to actually define every possible bool/tristate
Kconfig option twice (__enabled_* and __enabled_*_MODULE variants).

This results in a huge autoconf.h file, on the order of 16k lines for a
x86_64 defconfig.

Fixing IS_ENABLED to be able to work on the smaller subset of just
things that we really have defined is step one to fixing this.  Which
means it has to not choke when fed non-enabled options, such as:

  include/linux/netdevice.h:964:1: warning: "__enabled_CONFIG_FCOE_MODULE" is not defined [-Wundef]

The original prototype of how to implement a C and preprocessor
compatible way of doing this came from the Google+ user "comex ." in
response to Linus' crowdsourcing challenge for a possible improvement on
his earlier C specific solution:

	#define config_enabled(x)       (__stringify(x)[0] == '1')

In this implementation, I've chosen variable names that hopefully make
how it works more understandable.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use the ISO C standard compliant form instead of the gcc extension in the
interface definition.
Reported-by: NShachar Sharon <ssnail@gmail.com>
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>

this patch removes the pointer of uint64_t *edid. it should be just
a uint64_t.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

This patch replaces the old global setting of irq_virq_count that is only
used by the NOMAP mapping and instead uses a revmap_data property so that
the maximum NOMAP allocation can be set per NOMAP irq_domain.

There is exactly one user of irq_virq_count in-tree right now: PS3.
Also, irq_virq_count is only useful for the NOMAP mapping.  So,
instead of having a single global irq_virq_count values, this change
drops it entirely and added a max_irq argument to irq_domain_add_nomap().
That makes it a property of an individual nomap irq domain instead of
a global system settting.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Tested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>

We've been adding new mappings, but not destroying old mappings.
This can lead to a page leak as pages are pinned using
get_user_pages, but only unpinned with put_page if they still
exist in the memslots list on vm shutdown.  A memslot that is
destroyed while an iommu domain is enabled for the guest will
therefore result in an elevated page reference count that is
never cleared.

Additionally, without this fix, the iommu is only programmed
with the first translation for a gpa.  This can result in
peer-to-peer errors if a mapping is destroyed and replaced by a
new mapping at the same gpa as the iommu will still be pointing
to the original, pinned memory address.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Marc Merlin reported many order-1 allocations failures in TX path on its
wireless setup, that dont make any sense with MTU=1500 network, and non
SG capable hardware.

After investigation, it turns out TCP uses sk_stream_alloc_skb() and
used as a convention skb_tailroom(skb) to know how many bytes of data
payload could be put in this skb (for non SG capable devices)

Note : these skb used kmalloc-4096 (MTU=1500 + MAX_HEADER +
sizeof(struct skb_shared_info) being above 2048)

Later, mac80211 layer need to add some bytes at the tail of skb
(IEEE80211_ENCRYPT_TAILROOM = 18 bytes) and since no more tailroom is
available has to call pskb_expand_head() and request order-1
allocations.

This patch changes sk_stream_alloc_skb() so that only
sk->sk_prot->max_header bytes of headroom are reserved, and use a new
skb field, avail_size to hold the data payload limit.

This way, order-0 allocations done by TCP stack can leave more than 2 KB
of tailroom and no more allocation is performed in mac80211 layer (or
any layer needing some tailroom)

avail_size is unioned with mark/dropcount, since mark will be set later
in IP stack for output packets. Therefore, skb size is unchanged.
Reported-by: NMarc MERLIN <marc@merlins.org>
Tested-by: NMarc MERLIN <marc@merlins.org>
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix build warnings by providing a struct stub since no fields of
the struct are used:

include/linux/vgaarb.h:66:9: warning: 'struct pci_dev' declared inside parameter list
include/linux/vgaarb.h:66:9: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/vgaarb.h:99:34: warning: 'struct pci_dev' declared inside parameter list
include/linux/vgaarb.h:109:6: warning: 'struct pci_dev' declared inside parameter list
include/linux/vgaarb.h:121:8: warning: 'struct pci_dev' declared inside parameter list
include/linux/vgaarb.h:140:37: warning: 'struct pci_dev' declared inside parameter list
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Macros in <linux/pinctrl/machine.h> call ARRAY_SIZE(), the definition of
which eventually calls BUILD_BUG_ON_ZERO(), which is defined in
<linux/bug.h>. Include that so that every .c file using the pinctrl macros
doesn't have to do that itself.
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The pinctrl_register_mappings is defined in core.c, so change the dependent
macro from CONFIG_MUX to CONFIG_PINCTRL.

The compile error message is:
drivers/pinctrl/core.c:886: error: redefinition of 'pinctrl_register_mappings'
include/linux/pinctrl/machine.h:160: note: previous definition of 'pinctrl_register_mappings' was here
make[2]: *** [drivers/pinctrl/core.o] Error 1
make[1]: *** [drivers/pinctrl] Error 2
make: *** [drivers] Error 2
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It makes no sense to export this trivial function.  Make it a static inline
instead.

This patch also drops virq_to_hw from arch/c6x since it is unused by that
architecture.

v2: Move irq_hw_number_t into types.h to fix ARM build failure
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>

musb can be suspended at the time some other driver wants to do ulpi
transfers using usb_phy_io_* functions, and that can cause data abort,
as it happened with isp1704_charger:
http://article.gmane.org/gmane.linux.kernel/1226122

Add pm_runtime to ulpi functions to rectify this. This also adds io_dev
to usb_phy so that pm_runtime_* functions can be used.

Cc: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Also remove two warnings when CONFIG_SND_DEBUG is not set:

sound/pci/hda/patch_hdmi.c: In function ‘hdmi_intrinsic_event’:
sound/pci/hda/patch_hdmi.c:761:6: warning: unused variable ‘eldv’ [-Wunused-variable]
sound/pci/hda/patch_hdmi.c:760:6: warning: unused variable ‘pd’ [-Wunused-variable]
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch (as1536) fixes a bug in the USB serial core.  Unloading and
reloading a serial driver while a serial device is plugged in causes
errors because of the code in usb_serial_disconnect() that tries to
make sure the port_remove method is called.  With the new order of
driver registration introduced in the 3.4 kernel, this is definitely
not the right thing to do (if indeed it ever was).

The patch removes that whole section code, along with the mechanism
for keeping track of each port's registration state, which is no
longer needed.  The driver core can handle all that stuff for us.

Note: This has been tested only with one or two USB serial drivers.
In theory, other drivers might still run into trouble.  But if they
do, it will be the fault of the drivers, not of this patch -- that is,
the drivers will need to be fixed.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the control-rate tables are not set up correctly, it makes
little sense to spam the logs, thus change the WARN_ON to WARN_ON_ONCE.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Workaround dropped notifications in the iir register.  Register reads
coincident with new interrupt notifications sometimes result in this
device clearing the interrupt event without reporting it in the read
data.

The serial core already has a heuristic for determining when a device
has an untrustworthy iir register.  In this case when we apriori know
that the iir is faulty use a flag (UPF_BUG_THRE) to bypass the test and
force usage of the background timer.

[stable: 3.3.x]
Acked-by: NAlan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Reported-by: NNhan H Mai <nhan.h.mai@intel.com>
Reported-by: NSudhakar Mamillapalli <sudhakar@fb.com>
Tested-by: NNhan H Mai <nhan.h.mai@intel.com>
Tested-by: NSudhakar Mamillapalli <sudhakar@fb.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 448ac154.

The semantic of UPF_IIR_ONCE is only guaranteed to workaround the race
condition in the kt serial's iir register if the only source of
interrupts is THRE (fifo-empty) events.  An modem status event at the
wrong time can again cause an iir read to drop the 'empty' status
leading to a hang.  So, revert this in preparation for using the
existing "I don't trust my iir register" workaround in the 8250 core
(UART_BUG_THRE).

[stable: 3.3.x]
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Cox <alan@linux.intel.com>
Cc: Sudhakar Mamillapalli <sudhakar@fb.com>
Reported-by: NNhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We may hit this in xt_LOG:

net/built-in.o:xt_LOG.c:function dump_ipv6_packet:
	error: undefined reference to 'ip6t_ext_hdr'

happens with these config options:

CONFIG_NETFILTER_XT_TARGET_LOG=y
CONFIG_IP6_NF_IPTABLES=m

ip6t_ext_hdr is fairly small and it is called in the packet path.
Make it static inline.
Reported-by: NSimon Kirby <sim@netnation.com>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

Commit e52ac339 ('net: Use device
model to get driver name in skb_gso_segment()') removed the only
in-tree caller of ethtool ops that doesn't hold the RTNL lock.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit c16e981b2fd9455af670a69a84f4c8cf07e12658, because
it's no longer useful once MSI support is reverted.
Signed-off-by: NChris Ball <cjb@laptop.org>