They are not used, remove them.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use managed resources API to simplify the code.
Also ensure we do request mem_region before ioremap.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Then we can remove "select PINMUX && PINCONF" from PINCTRL_TEGRA{20,30}.
This simplifies the dependency.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Then we can remove "select PINMUX && PINCONF" from PINCTRL_IMX{23,28}.
This simplifies the dependency.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

They are not referenced outside of this file, make them static.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently pinmux_enable_setting does not release all taken pins if
ops->enable() returns error. This patch ensures all taken pins are
released in any error paths.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Both ltq_pinctrl_dt_node_to_map() and ltq_pinctrl_dt_free_map() are not
referenced outside of this file. Make them static.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NJohn Crispin <blogic@openwrt.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Current code adds empty ltq_pmx_disable() because pinmux_check_ops() requires
this callback to be defined.

This is not required since commit 02b50ce4
"pinctrl: make pinmux disable function optional".

Thus remove ltq_pmx_disable() function.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NJohn Crispin <blogic@openwrt.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Different SPEAr SoCs have different approach to configure pins as gpios. Some
configure a group of gpios with single register bit and others have one bit per
gpio pin. Only earlier one is implemented till now, this patch adds support for
later one.

Here we add callbacks to SoC specific code to configure gpios in
gpio_request_enable(). That will do additional SoC specific configuration to
enable gpio pins.

We also implement this callback for SPEAr1340 in this patch.
Signed-off-by: NShiraz Hashim <shiraz.hashim@st.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

They are not referenced outside respective driver.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Simon Arlott <simon@fire.lp0.eu>
Cc: John Crispin <blogic@openwrt.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most of SPEAr SoCs, which support pinctrl, can configure & use pads as gpio.
This patch gpio enable support for SPEAr pinctrl drivers.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.

So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.

This is done by:

- Adding a return code to gpiochip_add_pin_range() so we can
  reliably check whether this succeeds.

- Get rid of the custom of_pinctrl_add_gpio_range() from
  pinctrl. Instead create of_pinctrl_get() to just retrive the
  pin controller per se from an OF node. This composite
  function was just begging to be deleted, it was way to
  purpose-specific.

- Use pinctrl_dev_get_name() to get the name of the retrieved
  pin controller and use that to call back into the generic
  gpiochip_add_pin_range().

Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes us call gpiochio_remove_pin_ranges() in the
gpiochip_remove() function, so we get rid of ranges when
freeing the chip.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"

Introduced both of_gpiochip_remove_pin_range() and
gpiochip_remove_pin_ranges(). But the contents are exactly
the same so remove the OF one and rely on the range deletion
in the core.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"

Declared the of_gpiochip_[add|remove]_pin_range() global
while they should be static as they are only ever used in
this file. Let's convert them to static.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 69e1601bca88809dc118abd1becb02c15a02ec71
"gpiolib: provide provision to register pin ranges"

Got most of it's function prototypes wrong, so fix this up by:

- Moving the void declarations into static inlines in
  <linux/gpio.h> (previously the actual prototypes were declared
  here...)

- Declare the gpiochip_add_pin_range() and
  gpiochip_remove_pin_ranges() functions in <asm-generic/gpio.h>
  together with the pin range struct declaration itself.

- Actually only implement these very functions in gpiolib.c
  if CONFIG_PINCTRL is set.

- Additionally export the symbols since modules will need to
  be able to do this.
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Staticize sirfsoc_gpio_irq_map() function.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Staticize u300_pin_config_get() and u300_pin_config_set() functions.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This converts the U300 pin controller to use managed resources
(devm_*) for it's memory region.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This switches the COH 901 pin controller to use managed
resources (devm_*) for memory remaps, clocks, etc.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This switches the COH 901 pinctrl driver to allocate its GPIO
IRQs dynamically, and start to use a linear irqdomain to map
from the hardware IRQs.

This way we can cut away the complex allocation of IRQ numbers
from the <mach/irqs.h> file.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most of SPEAr SoCs, which support pinctrl, can configure & use
pads as gpio. This patch adds plgpio driver for configuring
these pads as gpio.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.

As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.

After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.

[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NShiraz Hashim <shiraz.hashim@st.com>
[Edited documentation a bit]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts earlier commit which removed
pinctrl_remove_gpio_range(), because at that time there
weren't any more users of that routine. It was removed as the
removal of ranges was done in unregister of pinctrl.

But as we are now registering stuff from gpiolib, we may
remove and insert a gpio module multiple times. So, we
need this routine again.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The of_device_id table is supposed to be zero-terminated.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The driver supports old up SiRFprimaII SoCs, this patch makes it support
the new SiRFmarco as well.
SiRFmarco, as a SMP SoC, adds new SIRFSOC_GPIO_PAD_EN_CLR registers, to
disable GPIO pad, we should write 1 to the corresponding bit in the new
CLEAR register instead of writing 0 to SIRFSOC_GPIO_PAD_EN.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Like the spear platform, the mvebu platform has multiple files: one
core file, and then one file per SoC family. More files will be added
later, as support for mach-orion5x and mach-mv78xx0 SoCs is added to
pinctrl-mvebu. For those reasons, having a separate subdirectory,
drivers/pinctrl/mvebu/ makes sense, and it had already been suggested
by Linus Wallej when the driver was originally submitted.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Including the core.h header for the pinctrl subsystem is not
necessary, and it is actually causing problems when moving the
pinctrl-mvebu drivers into a separate subdirectory.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The mach-kirkwood and mach-dove architectures have not yet been
integrated into the mach-mvebu directory, which should ultimately
contain the support for all Marvell SoCs from the Engineering Business
Unit.

However, before this can happen, we need to let mach-kirkwood and
mach-dove use the pinctrl-mvebu driver, which supports the kirkwood
and dove SoC families. In order to do that, we make this driver
available as soon as PLAT_ORION is selected, instead of using
ARCH_MVEBU as a condition. In the long term, PLAT_ORION should
disappear and be fully replaced by ARCH_MVEBU, but the plan is to make
the migration step by step, by first having the existing mach-*
directories for Marvell SoCs converge on several infrastructures,
including the pinctrl one.

Also, like the spear pinctrl driver, we put all pinctrl-mvebu Kconfig
options under a if, in order to avoid having certain options
(PINCTRL_DOVE, PINCTRL_KIRKWOOD, etc.) selecting an option
(PINCTLR_MVEBU) which itself has a dependency (on ARCH_MVEBU). In this
a construct, the dependency is in fact ignored due to the selects.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This switches the way that pins are reserved for multiplexing:

We used to do this when the map was parsed, at the creation of
the settings inside the pinctrl handle, in pinmux_map_to_setting().

However this does not work for us, because we want to use the
same set of pins with different devices at different times: the
current code assumes that the pin groups in a pinmux state will
only be used with one single device, albeit different groups can
be active at different times. For example if a single I2C driver
block is used to drive two different busses located on two
pin groups A and B, then the pins for all possible states of a
function are reserved when fetching the pinctrl handle: the
I2C bus can choose either set A or set B by a mux state at
runtime, but all pins in both group A and B (the superset) are
effectively reserved for that I2C function and mapped to the
device. Another device can never get in and use the pins in
group A, even if the device/function is using group B at the
moment.

Instead: let use reserve the pins when the state is activated
and drop them when the state is disabled, i.e. when we move to
another state. This way different devices/functions can use the
same pins at different times.

We know that this is an odd way of doing things, but we really
need to switch e.g. an SD-card slot to become a tracing output
sink at runtime: we plug in a special "tracing card" then mux
the pins that used to be an SD slot around to the tracing
unit and push out tracing data there instead of SD-card
traffic.

As a side effect pinmux_free_setting() is unused but the stubs
are kept for future additions of code.

Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Loic Pallardy <loic.pallardy@st.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NJean Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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>

One group definition was missing, so add it.
Signed-off-by: NJean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently there are some unnecessary criss-cross
dependencies between the PRCMU driver in MFD and a lot of
other drivers, mainly because other drivers need to poke
around in the PRCM register range.

In cases like this there are actually just a few select
registers that the pinctrl driver need to read/modify/write,
and it turns out that no other driver is actually using
these registers, so there are no concurrency issues
whatsoever.

So: don't let the location of the register range complicate
things, just poke into these registers directly and skip
a layer of indirection.

Take this opportunity to add kerneldoc to the pinctrl
state container.

Cc: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: NJonas Aaberg <jonas.aberg@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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>